Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: We just had an actual UUID v4 collision...

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 369 posts

Re: Ask HN: We just had an actual UUID v4 collision...

#161

Post by CodesInChaos »

This is usually caused by an insufficently seeded PRNG.

Are you generating the UUID in the backend, or the frontend? Frontend is fundamentally unreliable for many reasons, including deliberate collisions. So if that case you'll need to handle collisions somehow. Though you can still engineer around common sources of collisions, the specifics depend on the environment.

On the other hand making a backend reliable is feasible. What kind of environment is your code running in? Historically VMs sometimes suffered from this problem, though this should be solved nowadays. Heavily sandboxed processes might still run into this, if the RNG library uses an unsafe fallback. Forking processes or VMs can cause state duplication and thus collisions.

Re: Ask HN: We just had an actual UUID v4 collision...

#162

Post by jandrewrogers »

perching_aix wrote: post #118
jandrewrogers wrote: post #95

This 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?

I never blamed UUIDv4 for broken entropy sources. A broken entropy source breaks UUIDv4 even if you are using it correctly.

There is a long history of broken entropy sources showing up in real systems. No matter how hard people try to prevent this it keeps happening. Consequently, a requirement for high-quality entropy sources is correctly viewed as an unnecessary and avoidable foot-gun in high-reliability software systems.

Re: Ask HN: We just had an actual UUID v4 collision...

#163

Post by dist-epoch »

It's much more likely that you hit an "impossible bug" due to a bit flip somewhere.

Imagine the database having the old UUID in a memory buffer due to a recent index scan, and a bit flip happened somewhere in the logic which basically copied the old UUID into the memory location of the new UUID, or some buffer addresses got swapped, or the operation which allocated the new UUID received a memory buffer containing the old one, and due to a bit flip the memcpy operation was skipped, or something along that line.

Facebook wrote extensively about this, stuff like "if (false) {do_x(); )" and do_x being called. For example their critical RocksDB kv store has extensive redundant protections to defend against such "impossible bugs".

Re: Ask HN: We just had an actual UUID v4 collision...

#164

Post by whatevaa »

bitsandbits wrote: post #145
mittermayr wrote: post #23

Earlier quoted context omitted.

user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of app, where the same invoice must not be stored twice. So we used to generate a fresh invoice_id (uuidv4) on the user's device for each new invoice, and a double-send of that would automatically be flagged server-side (same id twice). This has since moved on to…

If the server or the user's phone had the wrong time and if the date is used in generating the ID...

uuidv4 is random. uuidv7 includes time.

Re: Ask HN: We just had an actual UUID v4 collision...

#165

Post by angoragoats »

georgemcbay wrote: post #160
angoragoats wrote: post #108

Earlier quoted context omitted.

No, the events are independent. If you have a UUID collide, your chance of winning the lottery if you enter it is exactly the same as it was before the UUID collision.

> If you have a UUID collide, your chance of winning the lottery is exactly the same as it was before the UUID collision. True, but only if you were already going to play the lottery anyway. If you don't normally play the lottery and the UUID collision combined with superstition is what enticed you to play, then the UUID collision will have raised your chances of winning the lottery from 0% to slightly higher than 0%…

Colloquially, when I say "your chance of winning the lottery" what I mean is "your chance of winning the lottery given that you enter." And I think you probably know this. But I've updated my post to be clear.

Re: Ask HN: We just had an actual UUID v4 collision...

#166

Post by victorbjorklund »

LocalH wrote: post #141
jandrewrogers wrote: post #95

This 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.…

This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…

If I understand it the Lava lamps are 90% PR/fun. They have a lot of other sources for entropy that scales better.

Re: Ask HN: We just had an actual UUID v4 collision...

#168

Post by ssalka »

throwaway_19sz wrote: post #50

Funny 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’…

At one of my previous jobs, there was a function `createEntityWithRandomUUID` which would basically do the same thing as a light wrapper around database inserts. If a conflict occurred, it would generate a new ID and try again, up to 5 times I think. No logging to indicate whether any conflict actually ever happened.

Re: Ask HN: We just had an actual UUID v4 collision...

#169

Post by ryanmonroe »

stanmancan wrote: post #142
nitsky wrote: post #136

Earlier quoted context omitted.

True, but it makes the specific collision the post observed completely impossible.

I left a more detailed comment on the parent, but it's definitely not impossible!

The scenario in this post is that the first uuid was created one year before the duplicate uuid. That isn’t possible with v7
Post reply on HN