password security question

Question

I'm working on a user authentication thing for a web site.

Having read the book Innocent Code, I have followed its advice for storing passwords as hash(username+password+salt). The theory being that hashing the password alone is not secure (subject to dictionary/rainbow table attacks, and potentially not a unique hash on any given site if more than one user uses the same password). Hashing the username and password together should be unique on any given site, but users may repeat these same credentials on different sites, so if it does get cracked on one, it could get cracked on many sites. So use a hash of username, password and a site specific salt value should make a globally unique hash (subject to the limitations of the hash algorithm itself)

I currently have two tables in the database: Users and Passwords.

The users table stores the user name and related information about that user (permissions, preferences, etc) but does not contain the password.

The passwords table is a single column table storing the hash of the password as described above. The hash is it's own primary key on that table. I've made the assumption that hashes should be sufficiently unique that I'm not ever likely to end up with duplicate hashes and therefore duplicate keys (Please correct me if I'm wrong in that assumption.) Authentication is done by recreating the hash from the user name and password supplied by the user (plus the secret salt) and checking if that hash exists in the db. If it's in there, they authenticate.

So far, this is working nicely.

Using this scheme, there should be no way to associate a password hash with any particular user. Knowing the user id won't help anyone find the corresponding password hash.

I'm not sure how I came up with this scheme. I thought I'd read it in the Innocent Code book, but I just read it again and it only goes to as far as hashing the passwords with a salt. It doesn't appear to suggest separating the passwords out of the user table.

Now my problem is that if I ever have to delete a user from the system, I have no way of knowing which password was associated with that account, so I can't delete any passwords. I can see ending up with orphan password hashes in the passwords table in the future.

So my question is: how should I be dealing with this?

Am I being paranoid by keeping the passwords separate from the users table? Creating a bigger problem for myself than I am solving? Would it really hurt to put the hashed passwords in the user table? Would it be better to have a single table dealing with all user information?

Answer 1

I don't think it would be a problem to put the passwords in the users table, seeing as you've already hashed them in a way that would make it very, very hard discover their original state.

Also keep in mind that the amount of work you put into securing the passwords should be somewhat in line with the other safety measures you have on the site. E.g., if the users send their password over a non-SSL connection, it wouldn't make much sense to put the passwords in their own table, etc., since crackers may be able to discover users' passwords just by listening in on the connection.

Answer 2

Yes, I think you're being paranoid, creating a bigger problem than you're solving, and that you should just put the hashed passwords in the user table.

If someone's dedicated enough to crack your username + password + salt, they're far more likely to just bribe someone at your hosting facility, an employee, or whatnot. If you're not VISA, this level of security is probably overkill.

Answer 3

It should be safe to store the hashed password with the user (you can also have random salts for each user too so the same salt isn't used for each password). If a hacker gets a hold of your database, if the password is hashed, it shouldn't matter if it's associated with a particular user (if you're really paranoid about it, you could always hash the user name too).

Answer 4

Let's assume your scheme is reasonable. If you orphan a password hash, and if your salt never changes, then you have to prohibit any future use of once-active usernames to prevent former users from getting into their namesakes' accounts. Any way you look like it, that's not likely to make you any friends. (At least not me; I dislike sites that won't let me re-register with my own name if long ago I had an account. I dislike even more sites that let someone else into my account...)

There's probably no "right" answer, but think about using something variable as part of the salt. For example, what if the salt were the hash of a user's account creation timestamp, itself salted with a value that you can calculate from that timestamp? Someone would have to figure out both your scheme for hashing passwords and the scheme for hashing timestamps, and the scheme for generating timestamp-hashing salt before the association of a user name to a password hash would be likely to compromise anything.

Then you could much more safely store the password+hashed-variably-salted-timestamp values in the users table.

Answer 5

The database is private (no public access)?
You are sure you don't have any SQL injection potential issue?
Your salt and hash key is protected? What would be the effect of having a security breach that allow access to the database tables and password hash? (at that point, the rest of the data will be my biggest concern...)

I don't think it worth the trouble to have the password hash in a separate table.