3

One of my colleagues is working on securing OAuth 2 client IDs and secrets for our OAuth server and he has come up with this scheme where he would not only use UUID v4 to generate random values, but also bcrypt them. Another colleague asked what's the purpose of bcrypt-ing them, to which he got the answer that just UUID v4 "loses 4 bits of randomness" (which would make the generated values more guessable).

The question seemed legit as far as my knowledge goes, but I couldn't find anything about the "loses 4 bits of randomness" part.

My question is if the usage of bcrypt here actually has an added benefit and, if so, how much added benefit.

I'm not very knowledgeable when it comes to cryptography, ciphers, crypto-secure random numbers and so on, so pointers to further reading related to this particular question would be appreciated.

Ionuț G. Stan
  • 135
  • 6

1 Answers1

5

UUID of type "v4" are supposed to be generated with 122 random bits:

o  Set all the other bits to randomly (or pseudo-randomly) chosen

   values.

However, it is not said that the said bits must come from a cryptographically secure PRNG (section 4.5 recommends it but does not mandates it).

IF the 122 bits indeed come from a secure PRNG, then they are immune to exhaustive search, because such a space is waaaaay too large for practical exploration (see this answer for more details). Adding bcrypt is thus just wasted CPU and gratuitous extra complexity, which is never a good thing, especially in security.

If the 122 bits are not produced by a secure PRNG, then you have a problem. It is conceivable that bcrypt might somewhat mitigate the issue, in the same way that bcrypt is good at tolerating passwords, which can only be described as "low entropy keys". But it really depends on how insecure the said PRNG is. A PRNG "security" relies on its unpredictability; here, "how much" the attacker does not know the 122 bits. If that "how much" is really low, then bcrypt won't save the day.

So my opinion is that when bcrypting an UUID is appropriate, then the UUID is not appropriate for use as a secret key, and you should fix that instead.

As for the "3 extra bits of randomness", this looks confusing, or confused, or both. I have no idea where that idea comes from.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Thanks for your answer. Makes sesnse. Regarding the "3 bits" part, he actually said that using just UUID v4 "loses 4 bits of randomness" (I've edited the question). Maybe that's related to something? – Ionuț G. Stan Jul 11 '14 at 14:24
  • 2
    This _might_ be related to the fact that an UUID is 128 bits, but only 122 are random (the 6 other mostly encode the fact that the UUID is "v4"). In that sense, it "loses" 6 bits (not 4) or randomness. But that's hardly an issue -- 122 bits are still a lot more than is needed to defeat exhaustive search. – Tom Leek Jul 11 '14 at 15:00