Wish they had included UUIDv1. Likely better than UUIDv4, but I'm curious how close it gets to UUIDv7 since it's already available.
What's the risk (in terms of "pwning") when the UUID is generated on a server?
Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf and assuming nobody will be able to download it without knowing the UUID
Step 3: Attacker predicts the UUID and downloads the private file.
Obviously the real solution here is to not use UUIDs as security keys - but dumbasses shoot towards their feet all the time, and UUIDv4 makes them hit less often.
I was kind of expecting some claim that actually exploits the inclusion of a hardware identifier, rather than "don't use predictable numbers as secrets".
Yes, they are. Still, it's not good security advice to point towards an other thing and say "this is even worse".
It's like complaining that a garden hose can be used to fill a car with carbon dioxide so we should recommend against using hoses in gardens.
> On a recent Code Assisted Penetration Test (CAPT) our team identified a vulnerability in a client's web application which allowed the consultant to bypass authentication and take over legitimate user accounts. The issue stemmed from the use of UUID version 1 in password reset tokens instead of the secure version 4 counterpart.
https://realizesec.com/blog/sandwich-attacks-exploiting-uuid...
You can probably sub in "suitably experienced" for "reasonable" if it reads better.
Look up the v1 spec. Essentially the entire ID space is timestamp + UUID, both of which are easily guessable.
The amount of entropy matters, and v1 has little of it. The danger here is that a UUID seems random when it really isn't.
Entering URLs wrong can also cause phishing breaches, that doesn't mean we stop using URLs does it?
Especially in a larger team you can't expect everyone to know fine details of every other part of the system. If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't.
I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors.
If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects.
Either we have very different ideas of what "mostly" means or you don't know what the different versions of UUID include as well as you think you do.
If we're considering the 5 published versions: 1 is built from random data; 2 are built from time & host data; and 2 are built from a namespace and a "name".
If we consider the 3 proposed additional versions: 1 is built from time & host; 1 is built from time & random data; and 1 is built from custom data.
So I personally wouldn't consider "most" to mean either 1 of 5 (20%) nor 2 of 7 (28.6%).
> I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors.
I would expect someone who is writing software and encounters UUIDs to take the few minutes needed to understand the basics of what goes into the different versions, ensure they're being used correctly.
> If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects.
They don't need to "hold the entire system in their head". They just need to (a) have the most basic understanding of what a UUID contains, and then (b) use it appropriately.
Sorry mate but not everyone gets to always work with the best of the best. I went through this exact exercise in the past and avoided v1 IDs because I suspected there is a risk they become externally exposed down the line, perhaps even years later when I'm gone.
I suppose you might decide otherwise and then blame others for incompetence instead if down the line someone failed to comprehend UUIDs like you so effortlessly do.
Please try re-reading what I wrote because you clearly didn't comprehend it the first time.
I never called anyone bottom of the barrel.
I said the reason not to use them is "bottom of the barrel", as in, it's a poor excuse for not using something, based on blatant misuse. Like saying "people mis-type URLs all the time, we should get rid of them" or "people get electrical shocks when they stick utensils in power outlets, we should stop using electricity"
https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-...
Obviously clients should use this variant as well if you're using v1.
RFC 4122 does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it.
The big problem - how can you tell for sure that is what is happening, and how would you catch a reversion if the underlying library changes behavior? Assuming you’re making a call into someone else’s stuff anyway.
A big challenge I’ve seen with UUID implementations is dependence on some kind of hidden system state that causes issues. like a MAC or nodeid file somewhere in a VM that gets cloned, resulting in duplicates where ‘duplicates should be impossible’.
https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-...