Security implications of using a non-hash in the password column



  • Imagine a webapp that uses a traditional email-password-login, with the users-table saving the password salted and hashed using bcrypt.
    Now a secondary login method should be implemented, like an API or external auth provider, with some users only being allowed to login via that secondary method, not the standard email-password-input.
    What are the security implications of populating the password field with an invalid hash, a string like 'NO-LOGIN', as to effectively disable the regular login? Would it be preferable to generate a random password and set a flag that disables the normal login for that user?



  • As long as the non-hash is chosen with some intelligence, some hypothetical (and largely historical) issues can be avoided.

    For example, if the non-hash was a magic hash - one that somehow accidentally had a valid plaintext - and an attacker discovered that plaintext, then that attacker could log in as any disabled user. (To keep things in perspective, the likelihood of accidentally using a magic hash as the 'disabled hash' is pretty low - but not zero.)

    Historically, this hypothetical issue has been avoided by adding characters to the existing hash - characters that are known to be completely invalid output of the hashing algorithm itself.

    For example, since classic descrypt hashes can only contain [0-9A-Za-z/.], adding a completely unrelated character - traditionally, the asterisk(*) - should be guaranteed to have no corresponding plaintext.

    Adding invalid characters, while leaving the rest of the original hash intact, also has the side effect of allowing the system to reactivate the user later simply by removing the asterisks. (And when this result is undesirable, simply replacing the entire hash with an algorithm-invalid character may be better.)

    Using some other completely invalid string, as long as it is known to be an impossible output of the hashing algorithm, should also be acceptable. But since that might require deeper knowledge of the algorithm, it might be harder to get right. Combining the two - both an invalid character and a human-readable label, such as:

    "*NO-LOGIN*[original-hash]"

    ... addresses this and is also a common idiom. (This can also be used to safely overload the hash field to store metadata about why the login was disabled - "*disabled-nonpayment*', etc.)

    Finally, note that this largely a historical issue. Only traditional DES crypt hashes (13 characters) are short enough to make accidental validity a practical concern. And overloading the hash field with status information should be a thing of the past. But it is important to understand the history to avoid future similar potential security issues.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2