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.
Re:UUIDs in MySQL are really not random
by dragontamer on Tuesday February 05, 2019 @02:28PM
(#19088819)
> 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.
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)