Contents
Do I need to hash username?
No, you should not. Otherwise, you could not show a list of registered users, or anything of that type. It would also make a lot of other functions unnecessarily clunky. Just use a one way digest method (such as bcrypt) on the user’s password with a suitably high work factor.
Should I encrypt usernames?
As usual, the answer is “it depends”. In general, I’d say that if an attacker has access to your database, your security situation is so badly compromised that encrypting the passwords will likely do you no favours.
When do you use a salt to hash a password?
When you hash the password the first time (when the user registers), you use a salt and store both the salt and the resulting hash in the database. The second time (when they try to log in again), you use your username to pull the salt and the hash out of the database. You use the salt to hash their password input, and compare the two hashes.
Why do user names spread hashes around less than a random salt?
Because user names have lower entropy than a random salt, so they spread your hashes around less than a proper salt does. Not that the example on that page is very spectacular anyway.
Why do I need to change my password hashing mechanism?
And changing your password hashing mechanism is a real pain because it means all the users have to change their passwords. The point of the salt is to be unique. The salt is meant to prevent attack cost sharing, i.e. an attacker trying to attack two hashed passwords for less than the twice the cost of attacking one.
Why are there so many duplicate password hashes?
If you didn’t use salts, or if you used exactly the same salt for every user (unfortunately not an uncommon mistake), there will be a lot of duplicate hashes (since some people will use the same password, and those identical passwords will all have identical hashes).