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

Goodbye integers, hello UUIDv7

buildkite.com

Post reply on HN
Print view View original

341–350 of 376 posts

Re: Goodbye integers, hello UUIDv7

#341

Post by noduerme »

Sebb767 wrote: post #320
cloverich wrote: post #306

Earlier quoted context omitted.

I think the counter argument is, that all else is not equal when obscurity is a goal of security, because it adds a maintenance burden to some greater or lesser degree, and that maintenance burden becomes time taken away from proper security practices, or other value providing work.

I think the main argument is that security by obscurity can easily be circumvented, be it via sidechannel, secret leak, source code leak or a surprisingly small search space (for example the whole range of IPv4 being scanned by now). It's easy to assume something is secure and spend a lot of time on obscurity, which completely falls apart thanks to a small sidechannel attack. It's (usually) just a weak defense overal…

To me, the main reason to avoid obscurity in naming or numbering things, or even in code - rather than view it as a modest addendum to security - is to force yourself to do the mental exercise of what happens when that obscurity is lost.

Not doing that is how small companies seem to get away with terrible security holes for a long time, until suddenly they don't. I've seen too many cases of companies in a position where they built a small, insecure service that's now getting shared more widely than envisioned, who don't want to spend the money to make it right, because no one has compromised it yet (that they know of), and what are the chances of someone stumbling across it - where even pointing out that it's an attack vector can earn you trouble.

Re: Goodbye integers, hello UUIDv7

#342

Post by kiitos »

travisjungroth wrote: post #96
kiitos wrote: post #66

Earlier quoted context omitted.

Second precision is too coarse for many (most?) use cases.

How so? It seems like the only real use case for these timestamps is to get data from around the same time together. A second is fine for that. It's not about concurrency or avoiding collisions. A second can't handle that, but neither can a millisecond.

> It seems like the only real use case for these timestamps is to get data from around the same time together.

Yep.

> A second is fine for that.

Not when you're doing O(1k-1M) operations per second, it isn't!

Re: Goodbye integers, hello UUIDv7

#343

Post by [deleted] »

phkahler wrote: post #258

Is there some reason new versions of UUID keep appearing? It seems like the desired properties are never quite achieved so new ones appear later. Is there a table with UUID version across the top and characteristics down the side, so I can see the differences and pick one that fits my needs? That might also help to explain why there are so many variants.

[deleted]

Re: Goodbye integers, hello UUIDv7

#344

Post by remram »

LAC-Tech wrote: post #185
oittaa wrote: post #120

Earlier quoted context omitted.

https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc... ULID isn't an "official" standard like UUID. Having a real standard usually promotes interoperability and makes it easier to use. Additionally as others have pointed out you can already use UUIDv7 with some databases since it's just 16 opaque bytes and the database doesn't care what's actually in the UUID field.

How much of a standard do ULIDS need? 6 byte timestamp, 10 bytes crypto randomness, stringify it using crockfords base 62 - and off we go.

Base 32, not base 62. Ironic.

Re: Goodbye integers, hello UUIDv7

#345

Post by pnpnp »

rtsil wrote: post #302
jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

Don't create them each time a record is created, create a batch in advance in sufficient number, and do the same every time the previous batch has ran out. UUIDv7 is 128 bits, you can store a large number of them without major penalty.

They’re also incredibly cheap to create & don’t need knowledge of each other. I mostly see batching of IDs like this when a lock is involved to prevent collisions & maintain performance.

With UUIDv7, you are reasonably sure that there won’t be collisions (check your use-case first), and can just generate them wherever on-demand (no locks required).

I’d argue batching IDs is actually more complicated than UUIDv7 for most use-cases.

Re: Goodbye integers, hello UUIDv7

#346

Post by pnpnp »

lightbendover wrote: post #263
sgarland wrote: post #243

Earlier quoted context omitted.

I’ve heard this argument many times, but I’ve never seen anyone actually post a reference to it happening (as in, a company finding and using this information; not the German tank problem). To me, it reeks of solving imaginary problems while causing new ones.

Years ago I wrote a library that would exaggerate sequential IDs to make our SaaS platform appear more popular than it actually was to anyone trying to pay attention. Not sure if I’m proud of the hack or embarrassed. But of both I suppose.

but UUIDv7 isn’t sequential (unless I’m getting it mixed up). There’s just a time-based component which can make sorting really nice & some random bits at the end.

If you don’t let an attacker iterate your data, all they can tell is when the ID was created.

Re: Goodbye integers, hello UUIDv7

#347

Post by pnpnp »

madeofpalk wrote: post #219
dalore wrote: post #203

Earlier quoted context omitted.

Having sequential ID's is more than just a security risk, it's an information risk. Competitors can use them to estimate the size of your business, the number of customers you have, and all sorts of stuff. This was used in the war to estimate the number of German tanks based on the sequential IDs https://en.wikipedia.org/wiki/German_tank_problem So just for business intelligence you don't want to leak your IDs.

Not disagreeing with the general concept - these IDs leak information - but these are sequential IDs, not auto-incrementing IDs. The leak is the time the ID was generated, not the volume of IDs generated.

They’re not even strongly sequential (is there a term for this?). The gaps between them can be arbitrarily large.

Re: Goodbye integers, hello UUIDv7

#348

Post by erik_seaberg »

Foobar8568 wrote: post #179
erik_seaberg wrote: post #114

Earlier quoted context omitted.

Usually Hive or Dremel, with rows ingested from frontend instance logs. I get that it would actually work on a smaller system with a single server assigning times (or a quorum, if leader election ensures a monotonic clock).

Thank you, I was just wondering if it was something I missed out on simpler systems and not distributed ones.

Nah, places I’ve worked are just choosing commodity hardware and geographically distributed systems over (very expensive) centralized ones.

Re: Goodbye integers, hello UUIDv7

#349

Post by Macha »

rtsil wrote: post #340
Macha wrote: post #308

Earlier quoted context omitted.

But then you need to have the client communicate with the server to identify it's newly created object or complicate your logic to have incomplete objects in a pending state, which is one of the things people were using UUIDs to avoid.

You don't store the UUIDs in the database as incomplete records. You can put them in a unused_uuids table and store some of the values in memory to minimize the round-trip. You can even store them in a simple file, and remove each used UUID from that file. When the file is empty, you create a million more of them.

The incomplete objects refers to when someone clicks "new" in your UI. Until it's saved back to the server, that "new" object has no ID, since you need to communicate with the server somehow to get that UUID in this approach. So now the client creates objects without IDs, so now all your models need to assume IDs are optional, and you can't create your object references on unsaved objects.

Re: Goodbye integers, hello UUIDv7

#350

Post by WorldMaker »

BillinghamJ wrote: post #322
jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

>Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implications. (e.g. knowing when session tokens or accounts are created). I don't think this is really true? These are not serially incrementing, they just indicate the time it happened. If you have an ID that you know exists, having the ability to know _when_ it was created is very…

One real world security problem is the "elder account" problem: as the age of an account increases the likelihood increases that it uses an insecure old password and/or that the account owner isn't paying as much attention to the account in the present. Depending on what the account represents age may also imply more "value" in the account. (Including just "sentimentality" value in the case of ransom operations, not just financial value.) Being able to tell from an ID alone that an account is at least X years older than some other ID in the system can be a handy way to find "potentially high value/low security" accounts to focus on to social engineer.

There are certainly mitigations that can be made and not all things are equally valuable as they age. (Plus many public APIs include created/modified timestamps anyway. The information is often easy to discover even when not embedded in an ID.) I don't find it a strong reason to avoid timestamp-based IDs for the threat models of that many things beyond user accounts and other things susceptible for social engineering, but it is something to keep aware of.

Post reply on HN