Accepting other similar passwords when storing a salted, hashed password

Question

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?

Answer 1

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.

Answer 2

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

abc123
Abc123
ABc123
abc!"§

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!

Answer 3

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.