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

301–310 of 376 posts

Re: Goodbye integers, hello UUIDv7

#301

Post by jabart »

dalore wrote: post #203
noduerme wrote: post #92

Earlier quoted context omitted.

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…

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.

They can still find out through LinkedIn, ZoomInfo, BuiltWith, and any number of tools.

The tank problem doesn't fit when the incrementing value is time since epoch. Integers yeah, UUIDs, KSUIDS, or any other semi-ordered thing to make your database indexes less fragmented I haven't seen a real leak issue with those.

Re: Goodbye integers, hello UUIDv7

#302

Post by rtsil »

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.

Re: Goodbye integers, hello UUIDv7

#303

Post by hannasanarion »

jacobgorm wrote: post #207
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…

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?

Re: Goodbye integers, hello UUIDv7

#304

Post by afavour »

RhodesianHunter wrote: post #246
afavour wrote: post #42

Earlier quoted context omitted.

Can’t agree with that logic. Unless it’s specifically documented leaking timestamp data is going to get totally forgotten. So when you add (e.g.) the ability to change the sent timestamp on a message you’re going to inadvertently leak when a timestamp has been changed. Could cause embarrassment in a lot of scenarios.

This sounds like a completely arbitrarily invented argument against a technology that's perfectly useful in many scenarios.

Inadvertently leaking private information is not an arbitrary argument.

Re: Goodbye integers, hello UUIDv7

#305

Post by sealeck »

RhodesianHunter wrote: post #249
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…

What's the risk of collisions with your external ID in this scenario?

I would imagine that they enforce this using e.g. a unique constraint in their database.

Re: Goodbye integers, hello UUIDv7

#306

Post by cloverich »

Sebb767 wrote: post #194
earnesti wrote: post #187

Earlier quoted context omitted.

Obscurity and secrecy are different things. Though I agree with you. Moderate amount of well implemented obscurity is helpful.

> Moderate amount of well implemented obscurity is helpful. You're getting that wrong: Everything else being equal, the more obscure system will always be the safer one. It's just that obscurity can easily be lost, so your system should, if in any way possible, still be secure even if fully known. In the end, however, no system is 100% secure, but more obscurity will make it harder to find the inevitably existing iss…

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.

Re: Goodbye integers, hello UUIDv7

#307

Post by netcraft »

jvolkman wrote: post #25
perfmode wrote: post #21

Earlier quoted context omitted.

What are the benefits of using the Postgres uuid type (versus using TEXT or VARCHAR)?

It's 16 bytes versus 36 bytes.

totally tangential to this but just have to share

learned this last week that md5's are also 128 bits and so will fit perfectly in a uuid type in postgres, saving space in the physical table and indexes, and giving better index performance. So if youre storing md5 hashes, use UUID!

Re: Goodbye integers, hello UUIDv7

#308

Post by Macha »

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.

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.

Re: Goodbye integers, hello UUIDv7

#309

Post by giancarlostoro »

afavour wrote: post #304
RhodesianHunter wrote: post #246

Earlier quoted context omitted.

This sounds like a completely arbitrarily invented argument against a technology that's perfectly useful in many scenarios.

Inadvertently leaking private information is not an arbitrary argument.

Sure but what are cases where knowing when a random GUID was created is actually an issue of privacy? Every platform I've seen using Snowflakes that exact same data is publicly available.

Re: Goodbye integers, hello UUIDv7

#310

Post by tabtab »

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…

Plus ID's often have to be given over the phone for support. Long or complicated ID's will drive both sides bonkers. #BeenThereDoneThat.
Post reply on HN