I was thinking about usernames and passwords and I was wondering how secure it would be to instead of the server having a list of usernames and accompanying hash of the passwords, just have a list of the password and username concatenated and then hashed, or something along those lines.

If someone could explain why this wouldn't work that would be great.


The problem of securely transmitting a username and password is a solved problem, HTTPS is elegant and works well.

In terms of this proposal it is significantly less secure than HTTPS, because this proposed system is vulnerable to a replay attack. Who cares what the username and password actually are, if you just login with hash(user+password), then this is the only value the attacker needs to know.

Secure hash based challenge responses usually innovate a causation where the server provides the client with a nonce, and then the hash(nonce+hash(password)) is used. The nonce can never be reused, Microsoft's NTML has had this problem "fixed" more than once.

After you login with the username and password you still need to protect the session id, which is the authentication token sued by the browser to maintain the authenticated state, so HTTPS is a good solution for this as well.

  • thank you, quick question, how do you verify that the password is the same if the nonce is always unique, what do you compare the hash(nonce+password) to, if it should always be unique,(I'm presuming that you don't keep a plaintext copy of the password anywhere on the server), unless the nonce is always the same for the same account, which I think you are saying you shouldn't do, but I am unsure. and thank you – Koios Nov 19 '13 at 17:09
  • @Koios in order to have a challenge response like NTML you would have to encrypt the passwords... which is a CWE-257 violation. Who says Microsoft cares about security? – rook Nov 19 '13 at 18:03

Your idea seems to be stemming from the fact that the same password run through a hashing function prints out the same hash value.

Rather than concatenating the password with the username, the preferred practice here is to concatenate the password with a unique random salt (just a big ol' random text blob) that is generated on the server when a user signs up. This salt, like the username, doesn't really need to be kept secret. The advantage over using a randomly generated blob vs the username is additional entropy.

You're thinking about this in the right way though. Adding something to the password before hashing it makes it more secure. It should ideally be something a little longer and more random than the username, though.


In the database, only the password is for authentication purpose and need to be protected as such, the login is for identification purpose. As an admin, you may need to access the user’s list, to lock or delete a user account or reset a password: impossible to do if all logins are hashed. You also loose on flexibility for a lot of usages (for instance, imagine some private messaging between users, very hard to implement when no one has any visibility over usernames).

That’s why in any users database, the logins (or any other kind of identification data) usually appears in clear form and only the authentication data is protected using a non-reversible method (like hash algorithms).

  • +1 for separating identity from authentication, which is the real problem. – John Deters Nov 19 '13 at 23:05

A fair few problems you need to overcome with this, the most of which I see are password-changing, password-reset, user administration, home directories (if applicable).

If you hash username and password together, then you'll most likely need to refer to users by an id number or something like that for admin (referring to it by hash would be rather insecure, and how would you know who was who?). The system would also be unable to verify a username was correct without the password.

To my mind, it would be more effective to implement another extra security measure, like 2FA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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