3 ms·

This is not very well thought out. 1) If you are generating API keys, those are presumably used to make API calls, and every such call has to verify that the A

This is not very well thought out. 1) If you are generating API keys, those are presumably used to make API calls, and every such call has to verify that the API key exists so it can deny or allow the request, which means that doing a lookup on any API key has to be an extremely cheap operation. So do the lookup after generating each and check for collisions. If you hit the jackpot and actually managed to randomly create a duplicate, generate another. Problem solved, and you don't have to worry about the collision frequency of your hash algorithm as a weird workaround for skipping a single extra lookup at API key creation. 2) Use GUIDs. It's what they're for. It's in the name. Globally Unique Identifier. This is the problem they solve.

rspeer 10y ago
GUIDs are Microsoft's implementation of UUIDs. UUIDs are long enough (128 bits) that you can generate them randomly and be confident in never getting a collision. That's what UUID4 is -- all but six bits (that's 122 bits) are completely random. Checking for UUID4 collisions is the height of paranoia. It's basically checking whether your PRNG broke. So your second recommendation is basically the same as the article's, and contrary to the first. Comparing UUIDs is not that expensive, but as expensive as it has to be for a key that will never collide.
- toast0 10y ago
  You'll never know if your PRNG is broken if you just assume it's not and don't check. Well, you might find out later, and have a lot of tricky cleanup.
- justusw 10y ago
  Comparing UUIDs is cheap, but avoiding non-constant-time compares is a necessity. So the usual for loop with an early exit when two bytes don't match up is poison. A web application could become susceptible to timing attacks. This is a good article that helped me understand and mitigate the vulnerability: https://codahale.com/a-lesson-in-timing-attacks/ https://codahale.com/a-lesson-in-timing-attacks/
- nitrogen 10y ago
  You also have to protect against an attacker guessing your next PRNG output, which is highly likely for non-crypto PRNGs even if they'll never collide with themselves. So always use the secure RNG from your language or OS for generating UUIDs.
justusw 10y ago
For those who are not sure about the difference UUID vs. GUID UUID = Universally Unique Identifier, RFC 4122 (https://tools.ietf.org/html/rfc4122.html https://tools.ietf.org/html/rfc4122.html) GUID = Globally Unique Identifier, the (mostly) Microsoft flavored version of UUIDs, used in partition tables as well Both of them consist of 128 bits, and both use 6 bits to denote the way the ID was generated, e.g. using the NIC MAC or timestamps. An overview over the different RFC 4122 UUID flavors can be found here: https://en.wikipedia.org/wiki/Universally_unique_identifier#RFC_4122_variant https://en.wikipedia.org/wiki/Universally_unique_identifier#...

rspeer 10y ago

GUIDs are Microsoft's implementation of UUIDs. UUIDs are long enough (128 bits) that you can generate them randomly and be confident in never getting a collision. That's what UUID4 is -- all but six bits (that's 122 bits) are completely random. Checking for UUID4 collisions is the height of paranoia. It's basically checking whether your PRNG broke. So your second recommendation is basically the same as the article's, and contrary to the first. Comparing UUIDs is not that expensive, but as expensive as it has to be for a key that will never collide.

toast0 10y ago
You'll never know if your PRNG is broken if you just assume it's not and don't check. Well, you might find out later, and have a lot of tricky cleanup.
justusw 10y ago
Comparing UUIDs is cheap, but avoiding non-constant-time compares is a necessity. So the usual for loop with an early exit when two bytes don't match up is poison. A web application could become susceptible to timing attacks. This is a good article that helped me understand and mitigate the vulnerability: https://codahale.com/a-lesson-in-timing-attacks/ https://codahale.com/a-lesson-in-timing-attacks/
nitrogen 10y ago
You also have to protect against an attacker guessing your next PRNG output, which is highly likely for non-crypto PRNGs even if they'll never collide with themselves. So always use the secure RNG from your language or OS for generating UUIDs.

justusw 10y ago

For those who are not sure about the difference UUID vs. GUID UUID = Universally Unique Identifier, RFC 4122 (https://tools.ietf.org/html/rfc4122.html https://tools.ietf.org/html/rfc4122.html) GUID = Globally Unique Identifier, the (mostly) Microsoft flavored version of UUIDs, used in partition tables as well Both of them consist of 128 bits, and both use 6 bits to denote the way the ID was generated, e.g. using the NIC MAC or timestamps. An overview over the different RFC 4122 UUID flavors can be found here: https://en.wikipedia.org/wiki/Universally_unique_identifier#RFC_4122_variant https://en.wikipedia.org/wiki/Universally_unique_identifier#...