

Ask HN: Best practices for creating unique IDs - Rust

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.<p>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.
======
Quarrelsome
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). :)

~~~
Rust
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 ;)

~~~
elptacek
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?

------
ratsbane
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.

------
dan_sim
You can take a look at this : [http://www.rubyfleebie.com/encryption-with-
alphanumeric-outp...](http://www.rubyfleebie.com/encryption-with-alphanumeric-
output/)

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

------
johkra
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.

