Need a unique & incremental user ID / salt - should I generate server side or in database?

All,

This is a fairly specific question and I suspect there's no perfect answer.

Goal: For a website, I want to generate during user registration a unique string that is incremental (so no GUID). This string is going to be primary key in the user table in the database, and is also going to be used to salt a password before hashing. The userID is not visible by the user - it's used only for internal purposes.

Question: Where and how should I generate the string? Options I'm considering are:

1 - Generate in the PHP code using uniqid("").

I can set up a loop that re-attempts to insert the new record as long as the insert fails (i.e., when the userID already exists, if two users attempt to register exactly at the same microsecond...).

Pros:

• I can use the userID to salt the pw without having to hit the db. Ideal case for user registration is a single db transaction.
• The string has a known format (length).
• The string is not random but is complex enough to be a good salt.

Con:

• The string doesn't contain any easily available information that I could otherwise find useful. That fact alone might negate any benefit from it being sequential, since I'm less likely to query for ranges of unique IDs if they are otherwise meaningless.
• I risk collisions if code is distributed. (SQL will prevent actual collisions from being registered, but it might slow down things.)

2 - Generate in MySQL using an auto-increment identity or sim开发者_如何学Cilar field.

Pros:

• No risk of collision slowing down the registration.
• The number generated contains useful info, i.e., the rank of the user.

Cons:

• The field doesn't add much complexity at first as a salt for the pw hashing process.
• String length varies overtime.
• I need to query the db for the string in order to do the salting and hashing - so each registration hits the table twice at least. (I could come up with a different string generation in php to create a salt, but then I would have one more column).

I don't have enough knowledge or experience to weigh those pros and cons, and I'm sure I'm missing some. I would appreciate any help you may bring...

Cheers,

JDelage

Probably not the answer you are after, but given that a salt should be composed of random bits I'm not sure that using an incrementing integer or string is the best thing to do. Why not just use the (auto-incrementing) PRIMARY KEY of your user table as a user id and use a separately generated salt for hashing? I think this will also resolve a lot of the trade-offs you have noted in your question.

Edit: Thinking about this a bit more having the salt as a user id completely defeats the point of salting stuff anyway: if your db is compromised then any hacker will have access to your salts. I think a better plan is to use a single salt, possibly hard-coded in code (so not in the db) to hash all user passwords.

You want to MySQL to manage it as an auto-increment.

Doing it in PHP means that as your user database grows, the number of queries you need to run to figure out what the next available number is grows. if you 50,000 users, thats a lot of queries to run. and there are issues with collisions.

As to your cons using MySQL auto-increment

1. changing a single character in the string will significantly change the hashed result
2. why is this an issue?
3. You dont have to run another query to get the auto-generated ID, just use mysql_insert_id ()

In general, you'd be better creating a unique random salt for each user. that will solve all the above issues, and be more secure.

Please see Ahmet alp Balkan's response to my other question here: PHP - Is uniqid("") a good practical solution to generate a unique and sequential key server side? . The answer suggest that uniqid("") is the right approach as the risk of collision during a given microsecond is minimal to nonexistent.