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?

  • 6
    Using an invalid password (something that cannot be constructed as a hash) has been the standard way to disable login on Unix-like systems for decades, and I know no security question involved. It may be simpler on an application level to use a distinct flag, but this is a general application design question and no longer a security one. Jun 22, 2021 at 13:45
  • 2
    I think this is a legitimate security question - even if the answer is 'there are no security implications'. And it's possible that someone might know of some. Jun 22, 2021 at 16:24
  • @SergeBallesta My question is merely about security issues and unintended side effects that could arise from such a solution, not about ease of development :) I am happy to hear this method is tried and proven. My proposed solution being standard is nice to hear (and does not invalidate the question itself).
    – René Roth
    Jun 24, 2021 at 10:15

1 Answer 1


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:


... 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .