Right now the client secret is generated by creating a new uuid(v4?) string, which has a predictable length and despite it being 32 chars long without the dashes it’s only using [0-9a-f] characters.
example a481c2ef-2baa-4ced-9e5c-53d38b42d98f
The dashes are always at predictable locations. I’m aware that 32 characters are hard to brute force, however uuid isn’t using the whole alphabet and also isn’t using special characters, so “entropy” for a lack of a better word should be increased. Generating a new uuid as a client secret is “lazy” and should be replaced by a less predictable generation strategy with more variety in the characters used.
To my knowledge there is no way in the console to manually set a client secret.
128 bit entropy seems to be very solid value to me. Did I make any mistake in my calculation?
Of course it can be worse if no random generator is used for uuid. We can also target higher entropy, e. g. 256, which seems to be current limit for bruteforcing techniques.
Herrgott im Himmel wie kann man nur so Begriffsstutzig sein!
That’s not what this is about and you know it.
Read the initial post if it’s not clear to you what the issue is about.
Keycloak generates weak secrets. That has to change. Idk what’s so hard to understand about that. Those 128 bits become way less when displayed in a hex representation.
If you really are as smart as you pretend to be, you would know that this forum is not the right place to suggest or demand changes to/for Keycloak. There are other ways to get in contact with the team and suggest serious issues, if there are any.
There’s a vast amount of misinformation out there on password strength. In this case, the locations of the dashes are unimportant; the attacker still has to generate 32 characters from a set which has 36 members (a-z0-9). There are therefore 36^32 potential selections, and the attacker could be expected to guess the correct one in, on average, (36^32)/2 attempts.
Unless there’s a flaw in the random number generator, and the attacker knows about it, this has an entropy of log2(36^32), or over 165 bits, which is absolutely massive, not ‘weak’ (‘strong’ is usually considered to be 75 bits). In this case, you could reach an entropy of over 77 bits with only 15 characters, rather than 32. Consider also that, in a brute force attack, simply knowing the current guess isn’t nearly sufficient -you have to do a lot of work to test every guess.
In Keycloak 23, secrets appear to be 32 characters in the set (a-zA-Z0-9), which has 62 members. The entropy in this case is over 190 bits. In other words, pointlessly strong.
One surprising thing that drops out of the numbers is that when you have reached a reasonable number of characters (generally way less than 32) adding extra ‘special’ characters to your character set is pretty much pointless. They’re difficult for you to remember (assuming you have to remember them) and they add no realistic security at all. Twice the age of the universe is just as unrelaistic as the age of the universe.
A version 4 UUID is randomly generated. As in other UUIDs, 4 bits are used to indicate version 4, and 2 or 3 bits to indicate the variant (102 or 1102 for variants 1 and 2 respectively). Thus, for variant 1 (that is, most UUIDs) a random version-4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of 2122, or 5.3×1036 (5.3 undecillion) possible version-4 variant-1 UUIDs. There are half as many possible version-4 variant-2 UUIDs (legacy GUIDs) because there is one less random bit available, 3 bits being consumed for the variant.
As @dasniko pointed out, if you are concerned regarding the security of the secret you should probably not use pre-shared secrets in the first place and switch to something stronger. The entropy is probably the least of your worries.
Curious - I scanned the OP’s post and read the secret as 32 [ASCII] ‘characters’, and you’re reading it as 32 hex numbers, which obviously has a much lower entropy. I don’t know that version of Keycloak so I’ve no idea what format the secret actually had then. In 23.0.1 the secret I’m seeing is actually 32 ASCII characters in the set [A-Za-z0-9].
Still, it hardly matters, as you say. Whatever format the secret actually had then, it was ‘strong’.
