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