| Secure? These fuuids are supposed to replace regular uuids, which aren't specified to be secure either. UUIDs are supposed to be quasi-unique (very low probability of collisions), not secure. They are, in my humble opinion, the wrong tool if you want secure. >Why not encode geolocation or IP while they're at it. Version 1 (and 2) of UUIDs encoded the MAC-Address + ns timestamp. So there you go. Version 3 and 5 just hash a namespace string and a name string with md5 and sha1 respectively (same inputs generate same output) Version 4, which these days is used by almost everything, just uses whatever pseudo-random numbers the implementation chose to use. If you can figure out what PRNG (pseudo-random number generator) was used (if any) and the internal state of that PRNG, then you may be able to guess/forge UUIDs. The spec does not mandate using a cryptographically-secure PRNG, although a lot of implementations out there today will probably use one. Anyway, thinking UUIDs would be secure is wishful thinking, unless you did the legwork to make sure you control the generator, and the generator you use is using Version 4 with a cryptographically-secure PRNG, and you can guarantee that that will not change in the future; then you get 122 bits of secure random numbers (+ 6 static bits for version and variant). By comparison, this implementation of "fuuids" gives you 96 bits of secure-enough random numbers or 64 bits in the nanosecond case (it uses os.urandom(12) and os.urandom(8), compared to os.urandom(16) that the standard lib in python uses) |
With sortable IDs, you could potentially know when some item was generated, which may or may not be useful info, but why take the risk? I think it makes sense to minimise the data that the app or service exposes. With a regular uuid you can control whether you expose or not the creation time, while with sortable ids you can’t.