from Hacker News

Why UUIDs won't protect your secrets

by 8organicbits on 10/20/25, 11:16 PM with 59 comments

  • by shoo on 10/21/25, 1:35 AM

    > 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

  • by rkagerer on 10/21/25, 4:11 AM

    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 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.

  • by EGreg on 10/21/25, 2:06 AM

    "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
    `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.
  • by ctxc on 10/21/25, 3:31 AM

    I thought this article was just stating the obvious over and over?

    The answer is _always_ auth over obfuscation.

  • by nmilo on 10/21/25, 4:00 AM

    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
  • by monkaiju on 10/21/25, 1:22 AM

    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
  • by pcthrowaway on 10/21/25, 9:55 AM

    IDOR is not "Indirect Object Reference" it's "Insecure Direct Object Reference"
  • by ronbenton on 10/21/25, 1:30 AM

    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.
  • by lmm on 10/21/25, 1:10 AM

    Why would you use UUIDv7 rather than UUIDv4 though?
  • by pluto_modadic on 10/21/25, 2:07 AM

    ...the solution to IDORs is to authenticate each user and check authorization per object.

    full stop.