3 Answers
3

Assuming you can choose a predictable salt (assuming you are only concerned with rainbow tables) you could always salt/hash the password, send that and the username to the database, OR if you implement you salt/hash in the database and connect to your database securely you can send username and plaintext or reversibly encrypted password then do the verification, logging and return the session ID in one go.

If the salt is randomly assigned and stored in the database (you are concerned with complexity in addition to rainbow tables) or your database cannot do the salt/has or you cannot get a truly secure connection to the database then the approach you describe is probably best.

Assuming a reasonably good database and that you site isn't google I wouldn't worry about the performance in two trips too much and there are things you can do to make certain that the statements stay in cache in many databases. Often that helps more than reducing the trips.

+1 Thanks. I'm doing random salt and storing it in the DB. Granted, I'm not planning for the project to be as big as Google (I couldn't afford the bandwidth), and I would use caching as much as possible. If I don't hear any other responses on this question, I'll happily accept this answer. My biggest concern is that I was "doing it wrong" in the first place.
–
user2039Feb 10 '11 at 22:52

I am not a mysql guy, but I think they have some encryption functions and SSL support, so passing it encrypted or plaintext and doing the salt/hash in the db would not be an unreasonable option IMHO
–
BillFeb 10 '11 at 23:01

I did briefly flirt with doing the encryption / decryption in the database. I decided to do it in code instead, so that the API can handle that. I do think I'll stick with my original idea now, because the second step is technically an audit trail as opposed to the actual login step (semantics, I know). I'll add in some tests to check for performance on login under load later in the development stage. Thanks for your help.
–
user2039Feb 10 '11 at 23:09

Not to further complicate matters, but if you want a fail-secure audit trail you might want to consider logging the attempt before validating it. -- Good Luck regardless
–
BillFeb 10 '11 at 23:13

@Randolph Potter - wouldn't the database be handling it for the API as well?
–
JeffOFeb 11 '11 at 3:14

It would be nice to hash within the stored procedure. But I use a library to hash, and was too lazy too look up a hashing library that can be easily used in T-SQL.

One trip is more elegant, but the user will not notice 2 trips. It is NOT a bottle neck. Hell, google purposely increased their hits 16-fold with their suggest, and auto-search. They could have just sit back and waited for people to press the search button and reap the performance benefit. If google thinks a 16 fold hit increase on the world's most popular website is OK then I'm ok with 2 hits.