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.
Do not assume that it is easy to determine if a UUID has been
slightly transposed in order to redirect a reference to another
object. Humans do not have the ability to easily check the integrity
of a UUID by simply glancing at it.
Distributed applications generating UUIDs at a variety of hosts must
be willing to rely on the random number source at all hosts. If this
is not feasible, the namespace variant should be used.
UUIDv4 is the only version of UUID anyone should ever use, and it should be generated with a secure PRNG, so using UUIDv4 is fine for this purpose (it has 122 bits of entropy).
You’ll excuse me if i believe the text of the RFC over some unsubstantiated claim from some person on the Internet. Expecially regarding a security issue, where the RFC explicitly says it’s not secure, and you go “naah it’s fine”. The RFC could easily have said “only use UUID version 4 as secure identifiers”, but it didn’t; I choose to believe that it does this for a reason.
6. Security Considerations
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.
Do not assume that it is easy to determine if a UUID has been slightly transposed in order to redirect a reference to another object. Humans do not have the ability to easily check the integrity of a UUID by simply glancing at it.
Distributed applications generating UUIDs at a variety of hosts must be willing to rely on the random number source at all hosts. If this is not feasible, the namespace variant should be used.
① https://tools.ietf.org/html/rfc4122#section-6