In terms of having enough entropy for randomness, can we consider UUID v4 to be safe?

For example, generating a random password like

>>> import uuid
>>> uuid.uuid4().hex

would that be enough?

I read that it was an entropy of 3.4e38, which seems reasonable, but my concern is more about if it's potentially guessable (for example UUID v1 leaks the MAC address, and other sources like /dev/random might not be utterly safe).

  • 1
    If your using it as a password generator, if it's a valid v4 UUID is should be Cryptographic secure based on spec, but it still depends on the language and algorithm implementation. Also why not just generate a 38-char secure password from any of the numerous password generator libraries? – Shane Andrie Jul 25 '17 at 14:42

UUID4 does not rely on the machine's MAC address, from the documentation:

If all you want is a unique ID, you should probably call uuid1() or uuid4(). Note that uuid1() may compromise privacy since it creates a UUID > containing the computer’s network address. uuid4() creates a random UUID.

However, UUIDs of any kind do not promise to be cryptographically secure as it is not guaranteed in the RFC. Certain implementations may use a cryptographically secure random number generator, but I wouldn't rely on it. I would choose to use another library if that is what is needed. If you are using Python3 you can use the secrets library which has functions for doing just this.

| improve this answer | |
  • In practice, UUID v4 must use cryptographically secure random source because any other implementation could accidentally correlate with other systems generating UUID v4 values and cause duplicate values more often than RFC suggests. However, this obviously boils down to implementation quality and you have to verify the implementation of UUID v4 library you intent to use. – Mikko Rantalainen Sep 2 at 8:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.