0

This question already has an answer here:

Pretend that I have a website running which does not show any usernames on any page. Therefore, it would not be a problem to hash usernames. When the user logs in, the unhashed username is stored in a session. Using this unhashed username, specific user data can be obtained from the database and the username can even be displayed on pages for logged in users.

Would this add anything regarding the security of the data? And am I possibly missing some functionality which does not work when the username is hashed?

marked as duplicate by Steffen Ullrich, techraf, S.L. Barth, Matthew, Tobi Nary Nov 1 '16 at 11:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • To gain anything from this you would need to hash the username and the password together. If you hash them separately it takes twice as long and then you might as well just hash the password and double the cost factor for that hash. – Anders Oct 31 '16 at 22:27
  • 4
    Do usernames need to be unique? Cryptographic hashes are not guaranteed to be unique, just collision resistant in that it's hard to deliberately find a collision. – ewanm89 Oct 31 '16 at 23:17
  • If you hash the username and you need to have an unhashed username, then you have to store two values, remember, you can't get a value in cleartext from your hash, so ask yourself, is it functional for your system or application storing hash of usernames and usernmaes in cleartext? – hmrojas.p Oct 31 '16 at 23:31
  • 2
    What threat are you trying to protect your users from? – Ramhound Nov 1 '16 at 2:09
  • @hmrojas.p well thats the thing, I was not planning to store a plain username. Only a hashed one. – P.Yntema Nov 1 '16 at 7:07
3

Securely hashing the username in the database protects the confidentiality of that information in the event that your database falls into the hands of an attacker.

Be aware though that if you use the un-hashed username in other ways in your application that information may still be obtained by an attacker.

For example, you mention:

When the user logs in, the unhashed username is stored in a session.

If we assume that your session information is sent to the client as part of the normal http response for a logged in user (e.g. as a cookie), the username may be obtained by an attacker if they get access to that session token. OWASP advises against storing user specific information in sessions sent to a client.

Using this unhashed username, specific user data can be obtained from the database and the username can even be displayed on pages for logged in users.

In this case the fact that you can use an un-hashed username to lookup database information implies that there is some un-hashed user information in the database, which undermines the hashing of the username in the first place. Also, if the information can be displayed in pages, be aware that unless the connection between client and server is secured at the transport layer (TLS) then that username may be visible to an attacker.

-1

Personally, I'd say yes. HOWEVER, your searches turn into exact matches. No more fuzzy searching for John "something or other", because it just became a hash lookup.

The reason I say this is if someone dumps your database - you just handed out a target list.

But my communities never go by more than handles.

Not the answer you're looking for? Browse other questions tagged or ask your own question.