Why UUIDs won't protect your secrets
alexsci.com
alexsci.com
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
why would anyone who ever suggested such a thing not be relegated to permanent headlight fluid fetching duty?
The failure of depending on natural keys is simply highlighted by that problem.
Aren't those guys hammered nearly daily (at least weekly) with one real-world example after another about how natural keys aren't unique?
The bigger issue: I also wouldn’t be quick to assume I know the idiosyncrasies of all card systems, like whether they reuse numbers.
I've seen tables where primary keys were 7-10 columns long. It's a nightmare to work with when joining.
How do you store the payment instrument for a certain purchase?
And as I said, you can design it so that the ID expires periodically.
Then there is no problem using the natural key?
The selection is clearly labeled as "Unlisted", which I find pretty easy to understand. It's a term used on other sites as well (eg. Imgur) and is hopefully becoming colloquial. For those less certain, a tooltip with more detail about the implications could easily be added.
Please don't wall your gardens behind logon credentials. Too much of the web has already done this.
Obviously sensitive things like billing should be subject to strictly controlled security. But being able to share semi-private media in a low friction-way without forcing consumers of your content to log in or create an account is extremely handy.
I'll point out that users don't always have a perfect understanding of the security websites provide. I'm a fan of Krug's book, Don't Make Me Think, as a model for how users interact with website UI and I think that's often how users interact with security. If you expect users to read, understand, and retain technical information you're going to be disappointed.
For YouTube in particular I noticed a number of articles that explain how unlisted content can leak and how to recover from a leak, so I think the 'may' in the quote is quite correct.
Anyway, maybe I didn't fully comprehend your article, but it still seems a bit mysterious to me how a database of unlisted YouTube videos could exist. Is it just based on user submissions? If so, how are they finding the URLs to the videos in the first place? In my experience, the way they might leak is if the uploader mistakenly adds an unlisted video into a public-facing playlist, but that doesn't seem to me like it would be a common error among content creators.
You don't need to be technical to have a decent idea of what "Unlisted" means.
A pretty good analog are the days when White Pages had everyone's phone number printed in them. If you wrote your unlisted number on a billboard or gave it to someone else who compromised it, you wouldn't expect to retain your privacy. There are lots of things on the Internet that quack like a duck but bite like a snake; this isn't one of them. It does exactly what's written on tin.
It's unfortunate (if not surprising) that malicious individuals are compiling the digital equivalent of "Dark Pages", and I salute your effort to raise awareness of that risk amongst web developers.
I grant "Unfair" wasn't a precise enough word, I just felt at that point you slipped from spotlighting unintentional architectural oversights that are fair game, to advocating opinionated change to a deliberate design choice. Sometimes we need real scissors, not safety scissors!
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 areHow would that work? 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.
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.
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?
What?
The answer is _always_ auth over obfuscation.
For anyone with prior knowledge and experience of UUID, it should be common sense that UUID will not protect any secrets, because that's not what they're for. They're a relatively unique and unguessable identifier, that's all.
Don't use a random id for security 'cause once its known, it's insecure.
This article gives me a lot of AI vibes
All statements, no logic, no solution.
I use YouTube and AWS as example since they both have implementations that are vulnerable to IDOR, but I think they made the right call. Sometimes usability takes preference over security. Sometimes 'obfuscation' is better than proper authorization.
> There are use cases where the effort needed to individually grant users access outweighs the risk of using unlisted. Not everyone is dealing in highly sensitive content, after all.
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.
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.)
(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.)
The fact that this site exists says it all: https://unlistedvideos.com/indexm.html
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.
https://medium.com/google-cloud/understanding-uuidv7-and-its...
Though Cassandra is more like quasi-SQL than NoSQL, the bigger issue is that actually the clustering key is never used for sharding. So Cassandra (today) always puts all data with the same partition key on the same shard, and the partition key is hashed, meaning there's no situation in which UUIDv7 would perform differently (better or worse) than UUIDv4.
In DynamoDB, it is possible for sort keys to be used for sharding, but only if there is a large number of distinct sort keys for the same partition key. Generally, you would be putting a UUID in the partition key and not the sort key, so UUIDv7 vs UUIDv4 typically has no impact on DB performance.
full stop.