Ask HN: Best practices for creating unique IDs | Hacker News Reader

Ask HN: Best practices for creating unique IDs

7 pointsRust6 comments

Would you use your database's "auto increment" function, GUID function (if any), or simply assign a randomized alphanumeric string of N characters? Each method has pros and cons, but I have never been able to really settle on one. Lately I've been using random generation on the assumption that a sufficiently large number of characters (say, 32) makes the risk of duplication nearly non-existent - but not impossible.

When you've written something from scratch, which method have you most commonly used? I'm more interested in security than readability, but I can't find any data suggesting one method over another aside from the possibility of guessing an auto-incremented field.

View on HN

Do you have security concerns besides someone guessing the id? I always figured you just make sure you only allow authenticated users to edit/view the data they are authenticated to see.

I always figured people used GUIDs over ids to avoid the performance implications of re-pinging the database to get the new id. I would be cautious of creating my own GUID generation though. I'd assume that the db's GUID implementation is probably WAY better than anything one can hack together within a short time-frame.

I'm an auto-increment man (if I can get away with it). :)

My concern with security stems from the eventuality of exposing that identifier to a viewer, most likely through a link - maybe to their profile page, or (for example) to a specific node or post. More commonly, that ID would turn up as a hidden form field on a comments form, a simple right-click away.

I would expect that good authentication would negate the worry about this, but I don't always see every side of things ;)

Any value that you use to look up user information to populate a template is going to expose some information about how your application works, whether it's incremental or a GUID or a hash. There is some value in not having it be incremental in that it's not as easily fuzzable, but spidering the site will still cough up a bunch of valid values for the 'userid' parameter. Even if the form field is hidden.

What are you writing, anyway?

GUIDs (UUIDs) are not necessarily good for cryptography; some implementations or versions make it easy to predict subsequent values. Originally UUIDs were created to provide uniqueness in cases when you didn't own the namespace: http://www.ietf.org/rfc/rfc4122.txt

I'm trying to figure out a solution to a similar problem this week. I'm leaning towards an AES of an auto-increment ID + random salt and my coding partner wants to create a random MD5 hex digest and store it as a second key in the database. He's probably right but I'd like to avoid creating yet another index.

You can take a look at this : http://www.rubyfleebie.com/encryption-with-alphanumeric-outp...

It cares more about readability than security but I guess it is safe enough.

I read 15 Bytes from /dev/urandom, use base64 on it and cut of the last two padding characters.

That's 2^120 possibilities - just guessing a valid id will require a lot of luck and a collision is very unlikely.

Reply on news.ycombinator.com