I am designing a login system for a project, and have an issue about it requiring two trips to the database when a user logs in.User types in username and passwordDatabase is polled and password hash is retrieved for comparative purposes (first trip)Code tests hash against entered password (and salt), and if verified, resets the session IDNew session ID and username are sent back to the database to write a row to the login table, and generate a login ID for that session.EDIT: I am using a random salt.Does this design make sense? Am I missing something? Is my concern about two trips unfounded?Comments and suggestions are welcome.
Are two database trips reasonable for a login system?
design;database;security
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.