By that logic serial-type ids are unsafe for use too, and much more vulnerable.
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".
I'm aware of the contents of UUIDs, I just thought we were somehow past absolute bottom of the barrel "well this might be misused by someone who clearly has no idea what they're doing" before claiming things have caused "pwning".
Entering URLs wrong can also cause phishing breaches, that doesn't mean we stop using URLs does it?
Everyone, even experienced engineers can make mistakes. Calling that 'bottom of the barrel' isn't helpful.
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.
> If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't.
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.
Yes and anyone who doesn't meet your expectations is 'bottom of the barrel' in your book, you've made it clear.
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.
> anyone who doesn't meet your expectations is 'bottom of the barrel' in your book
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"
uuid_generate_v1mc() from the uuid-ossp extension uses a randomly generated mac, so no leakage and entropy is increased. The timestamp portion is a feature IMO, not a bug. It prevents index and page thrashing in Postgres. (Also doubles as a "created_at" field, but that's getting "tricky".
That's often an issue that people think attackers wouldn't got all the way because it's too cumbersome. "Reasonable" has a very imprecise definition.
> 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.
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".