4 ms·

Why UUIDs won't protect your secrets

• lmm 1y ago
  Why would you use UUIDv7 rather than UUIDv4 though?
  • magnio 1y ago
    UUIDv4 is much more scattered (i.e., uniformly distributed), which heavily degrades indexing performance in databases.
    • vrosas 1y ago
      This depends on the database and should not be written as gospel.
      • Tostino 1y ago
        Which databases doesn't it degrade performance with when used as an indexed field?
        • 8organicbits 1y ago
          UUIDv7 seems popular for Postgres performance improvements, but it causes issues with databases like Spanner. https://medium.com/google-cloud/understanding-uuidv7-and-its-impact-on-cloud-spanner-b8d1a776b9f7 https://medium.com/google-cloud/understanding-uuidv7-and-its...
          • kbolino 1y ago
            Lots of distributed, NoSQL databases work (or partially work) this way too (e.g., HBase rowkey, Accumulo row ID, Cassandra clustering key, DynamoDB sort key). They partition the data into shards based upon key ranges and then spread those shards across as many servers as possible. UUIDv7 is (by design) temporally clustered. Since many workloads place far more value on recent data, and all recent data is likely to end up in the same shard, you bottleneck on the throughput of a single server or, even with replication, a small number of servers.
            • findjashua 1y ago
              i think the standard recommendation is to do range partitioning on the hash of the key, aka hash range partitioning (i know yugabyte supports this out of the box, i'd be surprised if others don't). this prevents the situation of all recent uuids ending up on the same shard.
              • kbolino 1y ago
                Indeed. In fact, Cassandra and DynamoDB have both hash keys and range keys; I've edited my comment to be more specific.
            • kbolino 1y ago
              FWIW it looks like Cassandra doesn't belong on this list, and DynamoDB only with qualifications. 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.
    • crazygringo 1y ago
      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.
• monkaiju 1y ago
  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
  • inopinatus 1y ago
    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.
  • dpipemazo 1y ago
    You can use pre-signed URLs with CloudFront.
• ronbenton 1y ago
  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.
  • Forgeties79 1y ago
    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).”
  • mananaysiempre 1y ago
    > 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.)
    • Forgeties79 1y ago
      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 1y ago
        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.)
• shoo 1y ago
  > 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
  • colechristensen 1y ago
    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 1y ago
      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.
      • 2muchcoffeeman 1y ago
        Surely the next thought is “I don’t want customer CC leaking” regardless what your background is?
        • 1718627440 1y ago
          When you introduce another ID that, maps 1:1 to the old one what do you get?
          • 1y ago
• EGreg 1y ago
  "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-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.
  • thaumasiotes 1y ago
    > 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 1y ago
      > 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 1y ago
• pluto_modadic 1y ago
  ...the solution to IDORs is to authenticate each user and check authorization per object. full stop.
• ctxc 1y ago
  I thought this article was just stating the obvious over and over? The answer is _always_ auth over obfuscation.
  • apt-apt-apt-apt 1y ago
    Yeah, the article is a one-liner turned into a 500-liner: Don't use a random id for security 'cause once its known, it's insecure.
  • est 1y ago
    > this article was just stating the obvious over and over? This article gives me a lot of AI vibes All statements, no logic, no solution.
    • 8organicbits 1y ago
      Author here. I used a spelling and grammar checker, but nothing LLM based. I think AI generates very poor content so I think this is a criticism. I'll solicit any constructive feedback, I enjoy writing and would love to improve.
  • lioeters 1y ago
    Seems like the article was written as a personal journey of learning why UUID is not suitable for security or authorization in any way. 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.
    • ctxc 1y ago
      Yeah, I guess I expected something much more interesting when I saw it on the front page (and the other positive comments)
  • 8organicbits 1y ago
    Author here. I think you missed the nuance I was going for. 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.
• nmilo 1y ago
  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
• rkagerer 1y ago
  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.
  • 8organicbits 1y ago
    Author here, I think we're mostly in agreement. Unlisted is a great approach for usability, especially for content with low sensitivity. It's a risk versus effort thing. 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.
    • layman51 1y ago
      I vaguely remember seeing a small help text on YouTube when you try to share an unlisted video where they tell you as the user that it's unlisted and to "be mindful" about sharing it. I think most people who read that don't understand what that means so maybe that's why I believe they don't show it anymore. I wonder if it has anything to do with that `si` URL parameter that the Share button introduces into the URL. 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.
• pcthrowaway 1y ago
  IDOR is not "Indirect Object Reference" it's "Insecure Direct Object Reference"