User table has two columns: userid; salt. Password table has one column: hash(userid+password+salt). Login process: given userid and password, look up salt. C

User table has two columns: userid; salt. Password table has one column: hash(userid+password+salt). Login process: given userid and password, look up salt. Check if hash(userid+password+salt) appears in Password table. Password reset process: Given a userid and new password, change salt to a new random value and save to User table. Insert hash(userid+new_password+new_salt) into Password table. The old hash remains in the Password table and could still be used to log in, but in theory is useless because the salt has been destroyed. Implementation detail: Make sure the old salt really is destroyed. EDIT: After thinking about this, I think the reason not to do it is that it doesn't really win you much protection over the usual approach -- a single table with userid; salt; hash(userid+password+salt). In that scenario, if your database is stolen then the attacker will have to brute force each user password individually and compare it to the stored hash for that user. You hopefully used an expensive hash() algorithm so that will be a slow process. The only thing the separate table adds is an extra table lookup during each brute force attempt, which compared to the cost of hash() is basically free. So yeah, I don't think this really gets you anywhere. EDIT2: In fact, you get almost exactly the same effect by making your bcrypt()/scrypt() parameters one notch harder. Crypto primitives FTW.