If a website stores passwords as a salted hash, is it reasonable to accept similar passwords as correct?

For example, given the password stackexchange, does it dramatically decrease security if the website were to accept stackexchange, Stackexchange, or STACKEXCHANGE? The thinking here is that this will be easier for users. The first is the exact password, the second is in case the browser capitalizes the first character of their password, and the third password has inverted case, in the scenario where the user has Caps Lock on.

If someone were to get a hold of this database and try cracking the passwords, would allowing these additional combinations significantly reduce password strength?

  • 2
    Facebook currently performs the Capslock scenario. While it technically degrades security because multiple passwords can be used for access I think that the main security still comes from strength of the password itself.
    – RoraΖ
    Commented Oct 2, 2014 at 13:37
  • I can't recall any site that uses this, but some operating systems will tell you "Warning: caps lock is on!" when you select password fields.
    – IQAndreas
    Commented Oct 2, 2014 at 15:39

3 Answers 3


If someone were to get a hold of this database and try cracking the passwords, would allowing these additional combinations significantly reduce password strength?

I would argue that it would not in this specific situation. I highly doubt that they are storing three forms of the hashed password in the database, but rather hashing three different versions of the provided password and comparing it to the one hashed password that is in the database.

There is an interesting post on here that discusses how Facebook has this password functionality. and while it doesn't go into exactly what is going on in the background, the consensus seems to be that it is not a significant security risk.


The answer to this question depends on two factors:

  1. the attack vector
  2. the implementation of allowing different passwords

Websites should store passwords not in plain-text or any other form allowing to get the password from the saved value. Therefore usually a irreversible hash-function is used, so that only the hashes of the passwords are compared.

Now there are mainly two methods of allowing simmilar passwords:

1) (The bad one, should not be used, only for completeness) One could store many different hashes of the user's password in the database. Example: User enters 'abc123' as password, and saved are the hashes of


and so on. Now on login you hash the given password and look if it matches with any password of the user.

2) Only the hash of the real password is saved, and on login time the given password gets altered (if the original one doesn't match) and the resulting salts are compared to the one in the database.

Now to different attack vectors:

If someone gets the database described in method 1, the security is a little weaker than normaly, because there are many different hashes for the user and the chances are higher that one may be found. With the database from method 2, there is only one hash, and the exact spelling has to be found.

Generally speaking, you have more enthropy in your character space with the second method, because you make a difference between Upper- and Lower-Case letters.

For an attacker holding the database (as long as it is made the reasonable way) there is no security deficit with this approach.

But in the case of a brute-force attack on the website there is allways a higher chance for the attacker to successfully log in to the users account. Therefore additional actions have to be taken to prevent this kind of attack!


The simple answer is not really. The easiest way to achieve this would be to use a .ToLower() before salting and hashing, and the same when password checking.

However it is worth spending some time thinking about why you would bother. It isn't the browser doing the capitalisation after all, it is the user. It is no different from using @ instead of A or 3 instead of e.

In principle you should accept whatever the user enters as their password without messing with it.

Also, research seems to indicate that password length and not complexity is the best way to go Measuring the Effect of Password-Composition Policies.

  • 4
    I'm not so sure about using .ToLower(), as doing so means entering one of thousands of different combinations of stackexchange now authenticate the user, not just the 3 that I would check. This seems like it would definitely decrease security, as you now have 26 + 10 + num_of_symbols for each character in the password instead of 26 + 26 + 10 + num_of_symbols. Losing 26 options per character is a good chunk of your individual character variability. Commented Oct 2, 2014 at 15:07
  • I am not saying it is desirable, only that it doesn't make that much difference in the grand scheme of things. For example, the Australian Government (their ISM) currently recommends 10 digits complex or 13 non complex. 26 to the power of 13 is more or less the same as 60-ish to the power of 10. Both are 18 digits long which is plenty. Now in this case the questioner is specifically talking about a web site, so a password lockout after n tries should be implemented as well. n can be = to 1000's without introducing too much risk.
    – DodgyG33za
    Commented Oct 2, 2014 at 15:17
  • Oh, please don't use ToLower msdn.microsoft.com/en-us/library/… Commented Oct 2, 2014 at 17:54

You must log in to answer this question.

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