6 ms·
No, UUIDs aren't meant to be cryptographically unique. Session identifiers should be generated by your friendly neighbourhood crypto rng man
by __s 9y ago
No, UUIDs aren't meant to be cryptographically unique. Session identifiers should be generated by your friendly neighbourhood crypto rng man
- MichaelGG 9y agoIf you're not specifically requesting a time based ID, any proper uuid lib should just return 16 bytes of randomness from the system rng.
- johncolanduoni 9y agoNot quite, most generate v4 uuids which have a few fixed bits.
- nucleardog 9y agoGetting pedantic, but a proper uuid lib should be returning 122 bits of randomness, and six bits of fixed information that specify the uuid version and generation method ("random").
- MichaelGG 9y agoFor what purpose? Where's the real world reason and interop? Just because an RFC says to set some bits? Is there any code you're likely to hit in your app that actually cares?
- vog 9y agoI guess the purpose is to be able to put different UUID generation schemes into separate kind-of "namespaces". That way, a UUIDv4 (random) will never collide with a UUIDv1 (timestamp+mac+...), which again will never collide with UUIDv5 (SHA-1). So if one of the UUID generation schemes is flawed, these are easily filtered out, and moreover, will never interfere with any other UUID version/scheme.
- veeti 9y agoYou need to double check the library you're using. For example, older versions of the Python standard UUID library would fall back to an insecure RNG silently. It's easier to just read 16 bytes from /dev/urandom and encode it in hex/base64 yourself for a random token.
- johncolanduoni 9y agoThe ones most modern UUID libraries generate (v4 UUIDs, variants one or two) have 122 random bits from the OS's csprng and 6 fixed bits.