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.
