5 ms·

One reason I started using UUIDs for database IDs is in case I make an utterly incompetent mistake and leave a URL-hacking security hole somewhere, you still wo

One reason I started using UUIDs for database IDs is in case I make an utterly incompetent mistake and leave a URL-hacking security hole somewhere, you still would need to guess a ridiculous ID to get at anything useful. EDIT: I realize UUIDs are not "secure random" tokens and this isn't sufficient for real security, it's just a nice to have encumbrance if I screw up something I should've made secure in the first place. It's no substitute for doing your job right in the first place. :)

JoeAltmaier 11y ago
Some UUIDs are cryptographically secure. But maybe they are too expensive. I support UUIDs instead of nearly any other id space. They solve collision problems completely. Its time to stop managing ids.
- zeveb 11y ago
  > Some UUIDs are cryptographically secure. Not if they are RFC 4122 UUIDs (more accurately, they are insufficiently cryptographically secure): even the random ones are only 122 bits, which only provide 61 bits of security. UUIDs are still really, really useful. I don't recommend not using them unless one understands why and when not to.
- marcosdumay 11y ago
  > But maybe they are too expensive. Why would that be? You can fork your PRNG as many times as you have threads in initialization, so there's no need for IO. And secure ones do spend many times more CPU than the cheapest PRNG available, both would be a rounding error on the performance on nearly all real world work-loads. I'd support removing non-secure random functions from every standard library out there.
  - JoeAltmaier 11y ago
    We used UUIDs for every media stream in our media engine. Had to create about 15 per second during prime-time conference hours. It was 40% of our CPU load! So they aren't free.
    - dchest 11y ago
      15 per second for 40% CPU? ಠ_ಠ This is very strange. On my laptop: ~ $ python -m timeit -s 'import uuid' 'uuid.uuid4()' 100000 loops, best of 3: 14.2 usec per loop Which gives more than 70000 random UUIDs per second.
      - JoeAltmaier 11y ago
        Yeah we were using some cryptographically secure ones for some reason. Creating them in Java!
        dchest 11y ago
        Python's uuid4 is cryptographically secure, as far as I know. One UUID needs ~16 random bytes, my laptop's /dev/urandom gives about 14 MB/s (user-space PRNG can be much faster if needed). Ah, Java...
        JoeAltmaier 11y ago
        To be cryptographically secure, it must be unguessable. That's a higher bar than random, because many random number generators are guessable (i.e. completely predictable).
        marcosdumay 11y ago
        Linux /dev/urandom is cryptographically secure. The library you are using for creating those UUIDs must have some bug. My guess is they share the same generator for all threads on each machine.
        JoeAltmaier 11y ago
        From Wikipedia : "some people claim /dev/urandom as not recommended[who?] for the generation of long-term cryptographic keys"
- mosburger 11y ago
  Oh definitely, there are lots of reasons to use UUIDs. My case above is one of the sillier ones. :)

JoeAltmaier 11y ago

Some UUIDs are cryptographically secure. But maybe they are too expensive. I support UUIDs instead of nearly any other id space. They solve collision problems completely. Its time to stop managing ids.

zeveb 11y ago
> Some UUIDs are cryptographically secure. Not if they are RFC 4122 UUIDs (more accurately, they are insufficiently cryptographically secure): even the random ones are only 122 bits, which only provide 61 bits of security. UUIDs are still really, really useful. I don't recommend not using them unless one understands why and when not to.
marcosdumay 11y ago
> But maybe they are too expensive. Why would that be? You can fork your PRNG as many times as you have threads in initialization, so there's no need for IO. And secure ones do spend many times more CPU than the cheapest PRNG available, both would be a rounding error on the performance on nearly all real world work-loads. I'd support removing non-secure random functions from every standard library out there.
- JoeAltmaier 11y ago
  We used UUIDs for every media stream in our media engine. Had to create about 15 per second during prime-time conference hours. It was 40% of our CPU load! So they aren't free.
  - dchest 11y ago
    15 per second for 40% CPU? ಠ_ಠ This is very strange. On my laptop: ~ $ python -m timeit -s 'import uuid' 'uuid.uuid4()' 100000 loops, best of 3: 14.2 usec per loop Which gives more than 70000 random UUIDs per second.
    - JoeAltmaier 11y ago
      Yeah we were using some cryptographically secure ones for some reason. Creating them in Java!
      - dchest 11y ago
        Python's uuid4 is cryptographically secure, as far as I know. One UUID needs ~16 random bytes, my laptop's /dev/urandom gives about 14 MB/s (user-space PRNG can be much faster if needed). Ah, Java...
        JoeAltmaier 11y ago
        To be cryptographically secure, it must be unguessable. That's a higher bar than random, because many random number generators are guessable (i.e. completely predictable).
        marcosdumay 11y ago
        Linux /dev/urandom is cryptographically secure. The library you are using for creating those UUIDs must have some bug. My guess is they share the same generator for all threads on each machine.
        JoeAltmaier 11y ago
        From Wikipedia : "some people claim /dev/urandom as not recommended[who?] for the generation of long-term cryptographic keys"
mosburger 11y ago
Oh definitely, there are lots of reasons to use UUIDs. My case above is one of the sillier ones. :)