Why UUIDs won't protect your secrets
27 comments
·October 20, 2025shoo
colechristensen
why would anyone ever think that using a credit card number would be a good primary key?
why would anyone who ever suggested such a thing not be relegated to permanent headlight fluid fetching duty?
ThunderSizzle
Well, there is a segment of the database side that thinks natural keys are better than artificial keys. A credit card number is a natural key, so I can see thr database logic to it.
The failure of depending on natural keys is simply highlighted by that problem.
monkaiju
Great piece, but worth mentioning that you generally can't use a presigned URL with CDN endpoints. So great for sensitive content, but if you rly want the thing to be widely and quickly accessible there's more work to be done
dpipemazo
You can use pre-signed URLs with CloudFront.
inopinatus
Well, you can if the signed URL is signed for the CDN's verification instead of the underlying storage.
Generalising this; you don't need stateful logged-in authentication to defeat IDOR, you can include an appropriately salted HMAC in the construction of a shared identifier, optionally incorporating time or other scoping semantics as necessary, and verify that at your application's trust boundary.
This tends to make identifiers somewhat longer but still fit well inside a reasonable email'd URL to download your phone bill without having to dig up what your telco password was.
However, note that one of the baseline requirements of privacy-oriented data access is issuing different and opaque identifiers for the same underlying thing to each identifiable principal that asks for it. Whether that's achieved cryptographically or by a lookup table is a big can of engineering worms.
EGreg
"Once the URL is shared with others, the owner loses the ability to assert access control over the video."
That reminds me of Stallman's apocryphal story about favoring a password instead of ACLs, and why GNU doesn't have a "wheel" group :)
https://administratosphere.wordpress.com/2007/07/19/the-whee...
Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual I'm on the side of the masses, not that of the rulers. If you arethaumasiotes
> Under the usual `su' mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.
How would that work? What is it about the wheel group that stops the sympathetic wheel from revealing his own login information to other people?
lmm
> How would that work? What is it about the wheel group that stops the sympathetic wheel from revealing his own login information to other people?
The wheel member probably doesn't want to reveal their own login information. They want to share the root password with other users; on systems without a wheel group that works, but on systems with a wheel group non-wheel users can't su.
thaumasiotes
> The wheel member probably doesn't want to reveal their own login information. They want to share the root password with other users
What's the difference? What would be something the other user could do in one of those scenarios that they couldn't do in the other one?
zzo38computer
If it is not possible to login as root directly (which on a multi-user system, it might only be possible to do if you are directly at the computer), then the wheel group might be one of the pieces (which should not be used alone; the wheel users still should avoid revealing the root password anyways) to protect against accidental telling the password, I suppose, since then other users cannot use the password without physical access to the computer. If they deliberately want to do so, then they could presumably just as well make the other users to also be the wheel group (or modify the software on the computer so that it does not require wheel, etc), if you have root access.
colechristensen
>What is it about the wheel group that stops the sympathetic wheel from revealing his own login information to other people?
Then there's a paper trail, bob logs in 10 times as much as anyone else and from all over the place.
Anyway this is all silly ancient politics and shared admin passwords as a method of freeing the people is long past relevant.
lmm
Why would you use UUIDv7 rather than UUIDv4 though?
magnio
UUIDv4 is much more scattered (i.e., uniformly distributed), which heavily degrades indexing performance in databases.
crazygringo
But mainly on writes, not much for reads.
And if your database is 99% reads 1% writes, the difference probably doesn't really matter.
And tons of database indexes operate on randomly distributed data -- looking up email addresses or all sorts of things. So in many cases this is not an optimization worth caring about.
ronbenton
I am a bit "meh" on the YouTube "unlisted video" example. The name itself is fairly transparent in implying that there's really no security, the video is just not listed in a public-facing way. This is significantly different than the article's billing example, where customers would be quite right in assuming their bills will be only accessible to them.
mananaysiempre
> The name itself is fairly transparent in implying that there's really no security
A password-capability system is a password-capability system. Not requiring an account does not make it not an access control. (Though it does make it e.g. not selectively revokable, which is a known weakness of password capabilities.)
BolexNOLA
Correct me if I am misunderstanding your point but unlisted YouTube videos don’t need a password or anything to be accessed. Anyone who has the URL can access it. It’s just not indexed/searchable on YouTube.
mananaysiempre
Right. And neither do Google Docs shared by a no-login link (which used to be the only option) or for that matter RSA signing keys. You could in theory guess any of these, given all of the time in the universe (quite literally). A “password capability” is any mechanism where knowing the designation of an object (such as the “unlisted” link) is a necessary and sufficient condition to access it. The designation has to be hard to guess for the system to make sense.
(The intended contrast is with “object capabilities”, where the designation is once again necessary and sufficient but also unforgeable within the constraints of the system. Think handles / file descriptors: you can’t guess a handle to a thing that the system did not give you, specifically, a handle for.)
BolexNOLA
Yeah at the end of the day the yt video isn’t under lock and key in any way, shape, or form vs. my billing info with my various utilities and such which is. It’s just “security through not knowing the exact URL (yet).”
pluto_modadic
...the solution to IDORs is to authenticate each user and check authorization per object.
full stop.
> If you use secret UUIDs, think of them as toxic assets. They taint anything they touch. If they end up in logs, then logs must be kept secret. If they end up in URLs, then browser history must be kept secret. This is no small challenge.
a fun retail banking variation of this misadventure is (1) someone designs an elegant RESTful API for doing something or other (2) and it gets applied to credit cards, where the credit card number is used as the natural primary key and is RESTfully embedded in URLs, which people endeavour to avoid logging, but then when you (3) integrate middleware to report metrics to some SaaS monitoring platform, the end result is that you're spraying all your customers credit card numbers into the monitoring platform