Some discussion here:
https://github.com/uuidjs/uuid/issues/546
Eg:
> FWIW, I just tested crypto.getRandomValues() behavior on googlebot and it is also deterministic(!)
Ask HN: We just had an actual UUID v4 collision...
121–130 of 369 posts
Re: Ask HN: We just had an actual UUID v4 collision...
#122Most plausible cause: uuid package depends on some random number generator package, which has recently been compromised in order to make “random” numbers predictable. As a result, many crypto (ssl + currency) projects are compromised due to a supplychain attack.
Changed 3 weeks ago: uuid/src/rng.ts : the random array is const. Every call will share the same random number. Subsequent call will update your old random code, so if you generated something important... good luck The old code used to do a slice() which creates a new copy. Might be unintentional. Although I have no idea how this would pass any tests, as you would think to test generating 2 randomnumbers and hope the…
https://github.com/uuidjs/uuid/blob/e1f42a354593093ba0479f0b...
became
https://github.com/uuidjs/uuid/blob/f2c235f93059325fa43e1106...
Welp.. time to patch and update everything again. Another day, another npm-package headache. Very odd()
Attack vector: call the rng(), and send the result somewhere. You now have now overwritten someone elses "random number" and know about it. The fun things you can do with those numbers!
Re: Ask HN: We just had an actual UUID v4 collision...
#123This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…
How is UUIDv4 to blame for a broken source of entropy? Or am I misinterpreting your words?
Presumably they mean using randomness as unique IDs.
Re: Ask HN: We just had an actual UUID v4 collision...
#124This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…
Thanks for the insight! Mind expanding on what alternatives are being used in high reliability systems instead of UUIDv4?
The latest UUID (7?) Uses half random gen, half timestamp. This not only makes it sortable by creation, but would also make a collision like this impossible.
Re: Ask HN: We just had an actual UUID v4 collision...
#125Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…
Pffft - they didn't need to store the whole UUID, just a hash. Dummies.
one hash is insufficent, they need k-hashes.
i get the joke, but seriously a bloomfilter would be a good idea.
Re: Ask HN: We just had an actual UUID v4 collision...
#126Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…
We have had a service to add two numbers. What make you think this is not realistic? :-)
Re: Ask HN: We just had an actual UUID v4 collision...
#127Earlier quoted context omitted.
Changed 3 weeks ago: uuid/src/rng.ts : the random array is const. Every call will share the same random number. Subsequent call will update your old random code, so if you generated something important... good luck The old code used to do a slice() which creates a new copy. Might be unintentional. Although I have no idea how this would pass any tests, as you would think to test generating 2 randomnumbers and hope the…
https://github.com/uuidjs/uuid/blob/e1f42a354593093ba0479f0b... became https://github.com/uuidjs/uuid/blob/f2c235f93059325fa43e1106... Welp.. time to patch and update everything again. Another day, another npm-package headache. Very odd() Attack vector: call the rng(), and send the result somewhere. You now have now overwritten someone elses "random number" and know about it. The fun things you can do with those numb…
Seems to be "safe" because of it's not exported, and the results get used in a different way. Still is a bug in my book.
Re: Ask HN: We just had an actual UUID v4 collision...
#128Fun thing about random is that these things happen. UUIDv7 is less prone to this as it includes both a time component and random. I’ve been using ULID in a few project which has similar attributes to uuidv7 but more space efficient.
Re: Ask HN: We just had an actual UUID v4 collision...
#129Funny story no one will believe, but it’s true. A good friend of mine joined a startup as CTO 10 years ago, high growth phase, maybe 200 devs… In his first week he discovered the company had a microservice for generating new UUIDs. One endpoint with its own dedicated team of 3 engineers …including a database guy (the plot thickens). Other teams were instructed to call this service every time they needed a new ‘safe’…
We have had a service to add two numbers. What make you think this is not realistic? :-)
I too have witnessed a "add two numbers" service! Turns out you can be too extreme with rules for isolating out business logic..
Re: Ask HN: We just had an actual UUID v4 collision...
#130the vm you're running on virtualized all the entropy away.
This seems very likely to be the case.
Something tangentially cool which is related: https://eu.mouser.com/new/leetronics/leetronics-infinite-noi...