> If you used UUID() for data that is supposed to be secret (like passwords)...
Since when someone on earth has recommended something like that?
UUIDs are time/mac address sensitive. They have version info within. They make an awful, guessable secret. It's just that: An unique identifier across the globe and not just your database.
A V4 UUID has 122 bits of randomness. Assuming your RNG generator has sufficient entropy, it would be perfectly valid to use the resulting UUID as a secret.
> Assuming your RNG generator has sufficient entropy
Why would you ever assume that? UUIDs could be formed from a low-entropy LCGRNG and still match the specifications.
Any secret should be generated with cryptographically secure random number generators. Calling "UUID" instead of like, BCrypt or something would be a major red flag to me. Heck, a modern cryptographically secure secret can be generated from Intel's "RDSEED" assembly instruction, which provides a hardware-random source of entropy, as well as entropy guarantees. (You'll probably use this assembly instruction if you are using /dev/urandom)
bcrypt is not a password generation (or password stretching) algorithm.
As always, it's the programmer's duty to investigate the RNG before relying on the entropy of some function's result.
UUIDs based on a CSPRNG and used as a password/token have some nice features--they're of fixed length, easy to validate for well-formedness, easy to serialize or deserialize in a variety of conventions.
Version 4 UUIDs pretty much have to be generated from reasonable(-ish) CSRNG. The assumption that the resulting 122bits are universally unique requires that they are truly chosen at random, CS(P)RNG is the most sane way to accomplish that.
> The assumption that the resulting 122bits are universally unique requires that they are truly chosen at random, CS(P)RNG is the most sane way to accomplish that.
Certainly not.
Take a Version 1 UUID (time-based), and spin it through a 128-bit LCGRNG. Do the AND / OR bitmasks needed to properly tag it a Version4 UUID and you're done. Bam, universally unique but not cryptographically random.
This would be very fast (cryptographic entropy is very slow!), and would be ideal for databases or most purposes.
Please don't ever roll your own security. Use a language feature (if available) or a third party library... though do a bit of due diligence on the third party library to make sure it's endorsed by a trusted source.
Since when someone on earth has recommended something like that?
UUIDs are time/mac address sensitive. They have version info within. They make an awful, guessable secret. It's just that: An unique identifier across the globe and not just your database.