8 ms·

Pretty much, my first reaction was "people use UUIDs for session tokens ? why? ? Seems like author made some bad choices in previous systems and now just figur

• epicureanideal 4y ago
  Depending on the UUID algorithm, some are cryptographically sufficient true random, then it would make sense..
  • ksidudwbw 4y ago
    what if you sha it?
    • WirelessGigabit 4y ago
      That actually reduces the usefulness as you're hashing the data into a smaller length.
      • unlikelymordant 4y ago
        It seems uuids are 128 bit, while sha is 160 bit. There is also sha256 and sha512 for longer hashed. So there shouldnt be any worries about the hash being shorter.
        • markatto 4y ago
          Yes, some hashes might not meaningfully hurt it, but they won’t add any entropy, which is the real problem.
        • jchw 4y ago
          Rereading I am guessing you're merely pointing out that the comment regarding shortening the length is untrue. If you already understand the entropy issue here, please treat my "you"s as royal you's. You have a 128 bit value. That's 128 binary digits. Each digit can be zero or one. That means you have 2^128 possible distinct values. (Ignoring the fixed bits in UUIDs since it's not important for sake of this argument.) Now you use a one-way cryptographic hash on top, like sha256. This will return a specific hash for any given input. It is always the same for a specific given input, and it is nearly always distinct. The output that a hash has may have more bits, but the number of distinct values can't increase; it can only ever decrease. That's because you could only ever give it 2^128 different values. How could it ever return more outputs if each input corresponds to one output? To make it more clear, let's say you have a database where you want to store a customer's zip code so you can use it as some kind of validation later on to ensure it matches, but you don't want to store it in plaintext, so you hash it. The hash is 160 bits. Secure, right? Wrong. There are less than 50,000 zip codes. It would be trivial to calculate the hash of every single one and use it as a simple hashmaps from hashed value to plaintext. You may be thinking this is impractical for an input domain as large as 2^128, but realistically it only adds a slight roadblock. Knowing the only valid values will be hashed UUIDs, instead of picking 160 random bits, you'd be much better off picking a random UUID, hashing it, and trying that for each attempt.
    • nine_k 4y ago
      Adding a crypto hash allows to check that the hashed value was not changed, because finding another value with the same hash is hard, by definition of a crypto hash. But here the problem is not forging an ID, it's guessing an ID, and hashing does not widen the search space, does not increase randomness.
      • dspillett 4y ago
        > Adding a crypto hash I think the poster you replied to was meaning using the hash output as the token, not that you would maintain the original token and a salted hash for verification. If they are thinking SHA(GenerateUUID()) would have better entropy then they are incorrect even though all SHA variants output more than the 128-bits in the source UUID. I assume such misunderstanding comes from the fact that some PRNGs are based upon repeated application of cryptographically assured hash functions against the seed data. Using some unreversible transform would solve the issue of potentially leaking information in the UUIDs, but if that is an issue then instead use a UUID variant based on purely random data (v4?) as that would be more efficient and not result in value that is longer but contains no extra entropy.
• hsuduebc2 4y ago
  From my experience even from bigger companies it is sometimes common practice.
• ak39 4y ago
  Not being snarky: what's the risk of using UUIDs for session tokens if they are created by the server/db and are always verified by server (db) (for authorisation etc)?
  • jve 4y ago
    Well, V4 UUIDS per wiki are pretty random, but your generated UUID could actually use your MAC address and current time to be globally unique. So, less entropy. Just use them as a (globally) unique thing but not as a secret.
    • whizzter 4y ago
      Basically, know your UUID generator type. V1, V2, V6 and V7 are mac/time dependant and more useful for f.ex. DB-keys whilst V4 is more useful for things that should actually be secret.
      • Gordonjcp 4y ago
        So there's nothing actually wrong with UUIDs as secrets, if you know what you're doing and how to mitigate the risks? So pretty much the same as every other damn thing in software that gets an "X Considered Harmful" article? :-D
        • mort96 4y ago
          I would trust a reputable cryptographic random number generator library to really care about generating truly unguessable, high entropy cryptography-grade random numbers. I would trust a reputable UUID library to generate a UUIDv4 which is random enough to not produce a collision. I would not trust a reputable UUID library to generate truly unguessable, high entropy cryptography-grade UUIDv4s.
        • scott_w 4y ago
          If you know what you're doing and mitigating the risks, you don't waste your time trying to use UUIDs for secrets. Therefore people using UUIDs for secrets, by definition, don't know what they're doing and certainly aren't mitigating the risks.
• jmull 4y ago
  I’m not sure it’s bad to use a random UUID (v4) generated with a random number generator designed for cryptography for a validated session key. A guess means making a request to your server. You won’t be concerned with ~2^64 guesses per second. I’m not suggesting anyone do it, if you have a choice. (Especially consider you’ll probably have to go through the trouble to justify it to people who read articles like this but don’t understand the math.) But if you have an existing system, consider whether you can let it stand.
  • ilyt 4y ago
    Well, existing system (that for whatever reason can't do CSPRNG-> base64) could always concat 2 UUIDs