Is UUID.randomUUID() suitable for use as a one-time password?

Question

As previous discussed, confirmation emails should have a unique, (practically) un-guessable code--essentially a one-time password--in the confirmation link.

The UUID.randomUUID() docs say:

The UUID is generated using a cryptographically strong pseudo random number generator.

Does this imply that the the UUID random generator in a properly implemented JVM is suitable for use as the unique, (practically) un-guessable OTP?

Answer 1

if you read the RFC that defines UUIDs, and which is linked to from the API docs, you'll see that not all bits of the UUID are actually random (the "variant" and the "version" are not random). so a type 4 UUID (the kind that you intend to use), if implemented correctly, should have 122 bits of (secure, for this implementation) random information, out of a total size of 128 bits.

so yes, it will work as well as a 122 bit random number from a "secure" generator. but a shorter value may contain a sufficient amount of randomness and might be easier for a user (maybe i am the only old-fashioned person who still reads email in a terminal, but confirmation URLs that wrap across lines are annoying....).

Answer 2

No. According to the UUID spec:

Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

Also, UUIDs only have 16 possible characters (0 through F). You can generate a much more compact and explicitly secure random password using SecureRandom (thanks to @erickson).

import java.security.SecureRandom; import java.math.BigInteger;  public final class PasswordGenerator {     private SecureRandom random = new SecureRandom();      public String nextPassword() {         return new BigInteger(130, random).toString(32);     } } 

---

P.S.

I want to give a clear example of how using UUID as a security token may lead to issues:

In uuid-random we discovered an enormous speed-boost by internally re-using random bytes in a clever way, leading to predictable UUIDs. Though we did not release the change, the RFC allows it and such optimizations could sneak into your UUID library unnoticed.

Answer 3

Yes, using a java.util.UUID is fine, randomUUID methods generates from a cryptographically secure source. There's not much more that needs to be said.

Here's my suggestion:

1. Send the user a link with a huge password in it as the URL argument.
2. When user clicks the link, write your backend so that it will determine whether or not the argument is correct and that the user is logged in.
3. Invalidate the UUID 24 hours after it has been issued.

This will take some work, but it's necessary if you really care about writing a robust, secure system.

Answer 4

Password strength can be quantified based on the required entropy(higher the better).

For a binary computer,

entropy = password length * log₂(symbol space)

symbol space is the total unique symbols(characters) available for selection

For a normal english speaking user with qwerty keyboard,

1. symbols are selected from 52 characters(26 * 2 for both cases) + 10 numbers + maybe 15 other characters like (*, + -, ...), the general symbol space is around 75.
2. if we expect a minimum password length of 8:

entropy = 8 * log₂75 ~= 8 * 6.x ~= 50

To achieve an entropy(50) for autogenerated one-time passwords with only hexadecimal (16 symbol space = 0-9,a-f),

password length = 50 / log₂16 = 50 / 4 ~= 12

If the application can be relaxed to consider the complete case sensitive english alphabets and numbers, the sample space will be 62 (26 * 2 + 10),

password length = 50 / log₂62 = 50 / 6 ~= 8

This has reduced the number of characters to be typed by the user to 8 (from 12 with hexadecimal).

With UUID.randomUUID(), two main concerns are

1. user has to enter 32 characters (not user friendly)
2. implementations has to ensure uniqueness criteria (close coupling with library versions and language dependencies)

I understand this is not a direct answer and its really up to the application owner to choose the best strategy considering the security and usability constraints.

Personally, i will not use UUID.randomUUID() as one-time password.