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

321–330 of 376 posts

Re: Goodbye integers, hello UUIDv7

#321

Post by jacobgorm »

hannasanarion wrote: post #303
jacobgorm wrote: post #207

Earlier quoted context omitted.

Not to speak of the increased risk of key collisions. https://en.wikipedia.org/wiki/Birthday_problem

In the same millisecond, in the same database system, having rolled the same 74 bit (~22 digit) number?

If it is the same database system, you may as well use a SERIAL or similar synchronized datatype. The point of using UUIDs is that any participant in a distributed system should be able to generate them, without having to rely on a centralized authority. If the use is purely local then UUIDs would be pointless.

If you have 74 bits of entropy, the birthday paradox says that after 2^37 keys you will hit a 50% risk of a key collision. Whether that is going to be a problem depends on the use case, and on the quality of your RNG.

Re: Goodbye integers, hello UUIDv7

#322

Post by BillinghamJ »

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 rarely meaningful.

What could present more of a risk is being able to predict a large part of IDs that will be created. Even then though, you shouldn't depend on your IDs for secrecy - best to ensure the IDs are never used as protection by themselves (ie treat them like they're just a simple autoincrementing number, even if they're not)

Re: Goodbye integers, hello UUIDv7

#323

Post by matja »

bajsejohannes wrote: post #152
matja wrote: post #144

Earlier quoted context omitted.

Curious on the preference there, especially when characters in base64url encoding can look similar/ambiguous in some fonts.

The preference is purely about the amount of characters. I hope no one will ever actually read or write these URLs, but you never know...

Ah in that case, base58 can be useful because it doesn't use characters that may be ambiguous in some fonts (doesn't use: 0/O/I/l , but does use: 1/i)

Re: Goodbye integers, hello UUIDv7

#324

Post by Someone »

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 business implication is that third parties can detect whether your sales increase or decrease from sampling those IDs (a variation on https://en.wikipedia.org/wiki/German_tank_problem)

Re: Goodbye integers, hello UUIDv7

#325

Post by lilyball »

aurbano wrote: post #190
lysium wrote: post #87

Earlier quoted context omitted.

Neat idea. I’m afraid you won’t be able to ever rotate that key, would you? Since it’s result is externally used as an identifier, you would have to rotate the external identifiers, too.

Assuming you have a table where the identifiers are stored you'd have the internal one (UUIDv7) and the encrypted version from it (external id). You could rotate encryption keys whenever you want for new external id calculation, so that older external ids won't change (as they are external, they need to stay immutable).

If you're storing the identifiers then you don't need encryption, you just generate a UUIDv4 and use that as the external identifier. And then we're back at where the blog post started.

Re: Goodbye integers, hello UUIDv7

#326

Post by Kunix »

dajonker wrote: post #115

Similar to the old situation in the article, we are using sequential 64 bit primary keys, but we use an additional random 64 bit key for external usage (instead of 128 bit). The external key is base64 encoded for use in URLs which results in an 11 byte string. This hides any information about the size of the data, the creation date of customer accounts (which would be sort of visible with UUIDv7) and prevents anyone…

I am using a variant of SnowflakeId [^1] in order to have 64 bit keys too.

It's similar to UUIDv7 (it leaks the creation time), but it's not an issue for me.

So I am able to have a single 64 bit key, which can easily be formatted into a small string for user-facing urls.

[^1]: https://instagram-engineering.com/sharding-ids-at-instagram-...

Re: Goodbye integers, hello UUIDv7

#327

Post by [deleted] »

tveita wrote: post #213
imiric wrote: post #97

Earlier quoted context omitted.

I'm a fan of Cuid2[1] for this reason. They are compact, don't leak information, and make a good case why k-sortable IDs are unnecessary, or even harmful for performance. I'm using sequential integers and created_at/updated_at timestamps for internal use, and Cuid2 IDs externally. [1]: https://github.com/paralleldrive/cuid2

> But not too fast: If you can hash too quickly you can launch parallel attacks to find duplicates or break entropy-hiding. For unique ids, the fastest runner loses the security race. > Cuid2 has been audited by security experts and artificial intelligence, and is considered safe to use for use-cases like secret sharing links. I'm getting some snake oil vibes from this... There absolutely shouldn't be anything like a…

[deleted]

Re: Goodbye integers, hello UUIDv7

#329

Post by gorkish »

logicchains wrote: post #215
woile wrote: post #103

Earlier quoted context omitted.

Could you explain a bit more how it would be a risk? Maybe for session tokens is understandable. But why leaking account created info is a problem?

Leaking a monotonic ID could allow outside observers to estimate e.g. number of accounts created or products sold over certain timeframe. Competitors (or traders, for a public company) could use this like a form of inside information on the company (e.g. sell the stock if the rate was falling).

This would really only be possible if you leaked a monotonic sequence; the monotonic clock only would potentially leak only event ordering or absolute time.

IMO it's not the job of the identifier itself to prevent information leakage vulnerabilities though; if thee is sensitivity to this, the solution should be explicit, such as employing a secondary key derived from the UUID using a secure KDF or similar.

Re: Goodbye integers, hello UUIDv7

#330

Post by Ginden »

wolverine876 wrote: post #314

> the random nature of standard non-time-ordered UUIDs (such as v4) can create database performance problems when used as primary keys. This problem is often referred to as poor database index locality. Couldn't that be solved with incremented serial numbers, rather than leaking time data?

Incremented serial numbers can leak things like eg. volume of sales in your shop.
Post reply on HN