> 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
show comments
rkagerer
This statement in the YouTube example is unfair: "Users may expect that the video has proper access control restrictions"
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 and 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.
show comments
nmilo
Title could have been “Python’s UUIDv7 only has 32 random bits” and just leave it at that. 2500 words to say “if you don’t authenticate access to a url then people can access it” wow shocker
pcthrowaway
IDOR is not "Indirect Object Reference" it's "Insecure Direct Object Reference"
ctxc
I thought this article was just stating the obvious over and over?
The answer is _always_ auth over obfuscation.
show comments
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 :)
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
`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.
I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
show comments
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
show comments
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.
show comments
lmm
Why would you use UUIDv7 rather than UUIDv4 though?
show comments
pluto_modadic
...the solution to IDORs is to authenticate each user and check authorization per object.
> 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
This statement in the YouTube example is unfair: "Users may expect that the video has proper access control restrictions"
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 and 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.
Title could have been “Python’s UUIDv7 only has 32 random bits” and just leave it at that. 2500 words to say “if you don’t authenticate access to a url then people can access it” wow shocker
IDOR is not "Indirect Object Reference" it's "Insecure Direct Object Reference"
I thought this article was just stating the obvious over and over?
The answer is _always_ auth over obfuscation.
"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.)
`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. used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.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
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.
Why would you use UUIDv7 rather than UUIDv4 though?
...the solution to IDORs is to authenticate each user and check authorization per object.
full stop.