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

161–170 of 376 posts

Re: Goodbye integers, hello UUIDv7

#161

Post by dgellow »

danwee wrote: post #154

So, how do you guys use UUIDs for real? I worked in a company in which they were using UUIDs in Mongo, and of the most painful things were implementing API endpoints that filter resources. Imagine you have an endpoint in which you are filtering by resources A, B, C and D. Ideally you would end up with something like this: GET /filter?a_id=X&b_id=Y&c_id=Z&d_id=w But in practice we were using POST and passing the ids i…

Do you dislike the use of POST because of its effect on caching, or because it doesn’t feel semantically correct? If you don’t need the caching I wouldn’t mind using a POST to filter.

Note that you can also use GET with a body, it’s not spec compliant (a body is allowed but not supposed to have any meaning) but is used by products such as Elasticsearch. If you control both clients and servers that’s something you can safely do (and use an etag header for idempotency).

Re: Goodbye integers, hello UUIDv7

#163

Post by nindalf »

oconnore wrote: post #55
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…

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

One key for all tokens or one key per token? If it’s the latter a simple XOR would do because it would be the equivalent of a one time pad.

Re: Goodbye integers, hello UUIDv7

#164

Post by lifthrasiir »

notpushkin wrote: post #91
dajonker wrote: post #85

Earlier quoted context omitted.

That's an interesting idea, how would you deal with the bits in the UUID that are used for the version? Setting them to random bits may cause issues for clients that try to use the identifier in their own database or application, as mentioned in the article.

Is there a way to encrypt 122 bits -> 122 bits? If so – do that and set version to 4. Alternatively, just say it's a random string ID and not an UUID.

For your information, yes, you can [1]. For example if you have a good enough 128-bit block cipher (e.g. AES-128-ECB), start with a block of 128 bits where specific 6 bits are filled out and others are filled with the plain text. Repeatedly encrypt the block until those specific 6 bits are reached again (and do the same thing in reverse for decryption). This is possible because a good block cipher is also a good pseudorandom permutation, so it should have a small number of extremely long cycles (ideally just one) with a 2^-6 probability of allowed values in average.

[1] https://en.wikipedia.org/wiki/Format-preserving_encryption

Re: Goodbye integers, hello UUIDv7

#165

Post by berkes »

noduerme wrote: post #136
berkes wrote: post #101

Earlier quoted context omitted.

Doesn't that still leak (statistical) information? It may not be technically security, but e.g. knowing your competitor just added N products to their shop, might be a security issue for the business.

It may. Certainly, for instance, sequential invoice numbers do. If a business decides to take measures to obscure that, no problem. All I'm saying is that obscuring a numbering system for data artifacts shouldn't be considered any sort of security as far as keeping your endpoints from being hacked.

The point on invoice-numbers brings another issue to mind.

We model our domain(s) using DDD, and often "The ID" really is best left a thing with meaning. Customer-id, Bank-account-number, invoice-number, email, etc. At least within the domain, it is. The business (and laws etc) already ensure there can only ever be one invoice with this number. Its terribly counterproductive to have two ID's for something. "Hey, can you have a look at invoice 20230233, because it seems the VAT was applied wrong. Hmm, do you have the UUID for that invoice and DM me that? You know, the long one with the hyphens".

I guess there isn't a one-size-fits all solution and that "it depends" very much on what e.g. "public" means.

Re: Goodbye integers, hello UUIDv7

#166

Post by dgb23 »

As a beginner I treated and understood (SQL) databases as something I have to use in order to store stuff.

Later I was excited about the power and expressiveness of SQL and its extensions. There is a ton of leverage and you can make it so that interfacing with it directly becomes much more useful.

However now I’m in a different phase. I see it as a durable data structure. I think in terms of “what does it provide to make the overall system better?”

The issues around indexing and uuids that is discussed in the article fits nicely into this line of thinking.

In web development, database access and performance often dominates and infects the whole system.

Re: Goodbye integers, hello UUIDv7

#167

Post by ivan_gammel »

noduerme wrote: post #92
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…

Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just…

Security by obscurity is a working solution if implemented with other measures. It increases the cost of attack, which in the presence of unknown vulnerabilities gives you precious time to respond.

Re: Goodbye integers, hello UUIDv7

#168

Post by foreigner »

dgb23 wrote: post #166

As a beginner I treated and understood (SQL) databases as something I have to use in order to store stuff. Later I was excited about the power and expressiveness of SQL and its extensions. There is a ton of leverage and you can make it so that interfacing with it directly becomes much more useful. However now I’m in a different phase. I see it as a durable data structure. I think in terms of “what does it provide to…

As a beginner I thought of the database as a backend for the app. Now I think of the app as a frontend for the database. :-D

Re: Goodbye integers, hello UUIDv7

#169

Post by [deleted] »

notpushkin wrote: post #91
dajonker wrote: post #85

Earlier quoted context omitted.

That's an interesting idea, how would you deal with the bits in the UUID that are used for the version? Setting them to random bits may cause issues for clients that try to use the identifier in their own database or application, as mentioned in the article.

Is there a way to encrypt 122 bits -> 122 bits? If so – do that and set version to 4. Alternatively, just say it's a random string ID and not an UUID.

[deleted]

Re: Goodbye integers, hello UUIDv7

#170

Post by eviks »

Always wondered what the point of dash-separating uuid if the separated parts are unreadable anyway just like in this version, just makes it harder to select as a single blob of text
Post reply on HN