Traditionally, a 'salted' hash of the password is stored along with the salt so there is no plaintext in the database and still be able to authenticate the password.

The salting process consists of appending the salt to the password string and then hashing the resulting string, right?

I just realized that if the password is an empty string, the salted password hash would be the same as the hash of the salt.

This is an obvious security issue since a stolen database would still leak information about the passwords if the attacker would simply hash all the salts and compare them with the salted password hashes; any matches would reveal empty passwords.

The obvious solution would be to limit the minimum password length.

The question is, am I missing something in my understanding of the traditional salting/hashing procedure?

I'm not asking how to securely store passwords, I'm asking whether a blank password does leak information or my understanding is wrong.

  • The pepper... Possible duplicate of How to securely hash passwords? – kelalaka Feb 1 at 23:35
  • 1
    Yes, you should enforce a minimum password length. This is in both the NIST standard and the PCI standard (which conflict about many other things, such as requiring non-alphanumeric characters, and periodically expiring passwords without evidence of a breech). I'd be very surprised if there is any standard that says blank passwords are okay. – Ghedipunk Feb 1 at 23:41
  • @Ghedipunk Thanks, that's what I though. – XArtur0 Feb 1 at 23:42

What if someone uses "abcd1234" as their password? This is an obvious security issue since an attacker could simply hash all salts with "abcd1234" and compare them with the stored hashes. Any matches would reveal that "abcd1234" is the correct password.

No difference really, an empty password is just another example of a bad password, among many others. The empty password can be trivially prevented by setting a 10-12 character minimum password length, but preventing bad passwords in general is non-trivial, and may never be truly solved while still letting users pick their own passwords (not that I'm recommending forcing random passwords, that would likely just result in more password resets).

Bad passwords can be somewhat mitigated by properly hashing so that each attempt takes an attacker a significant amount of time (tenths of seconds instead of microseconds), but if someone is determined to use a bad password, in the end there's not much you can do about it.

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.