Note the title is wrong but the linked response from Facebook describes what they actually do quite succinctly. So if you're coming straight to the comments, do take the 15 seconds to click through and read it!
You don't have to wonder if it "seems like going to far" because you can calculate almost exactly the reduction in the search space / entropy.
But don't just go based on the theoretical key space reduction. You have to look at the kinds of passwords that people actually choose and see if an online attack which gets on the order of 10 tries against a password before an account is locked would actually be marginally more effective because each submission is technically trying 4 passwords instead of 1?
The reality is the 4 additional tries that Facebook is giving you for free are not passwords that would be in the attacker dictionary in an attack which is allowed only 10-100 tries.
Whereas the 4 tries are probably at around 1% of the time, in other words billions of logins per year, result in a valid login for a user who knows the right password but simply failed to type it correctly.
Another key point to consider is if you give users these 4 extra tries for free on each submit, you cut down drastically (power law on the types of errors that users make) on the number of failed login attempts overall. When this happens you can now reduce the account locking threshold without catching a larger percentage of your real users in the "your account has been locked" trap. This results in a significant net improvement for security against online attack.
If an attacker knew it consisted of only [A, a] at random it would take 2^50 guesses. But now it only takes a single guess, just all A's. It's a toy example, but Facebook definitely isn't just giving four extra guesses for free.
Seems very reasonable to me. Similarly, I just had a friend comment that they like that Facebook tells them when they try to log in with an old password. But technically that makes it less secure for people who reuse passwords (ie everyone, to a first order approximation).
It's not case-insensitive. Try it. I knew they had the case-flipped version but I didn't know about the others. Why would a user's password have an extra character on the end anyway?
>Why would a user's password have an extra character on the end anyway?
That seems the strangest of them all: "If the login fails, try stripping a character off the end and see if that matches". I can understand the "First character inadvertently capitalized one" somewhat, but the CAPS LOCK thing seems unforgivable. I just did that yesterday with Apple and it simple suggested to me caps lock might be on. If your test for that is (password didn't match AND all alpha characters in the submission are capital letters) you don't even need to store a second hash for it.
I know there will always be trade-offs between security and UX but, if this image is accurate, that seems like going too far in favor of usability. No matter how small, multiplying the numerator in the probability of matching a password is a dangerous decision.
One wonders how they discovered these common mistakes. The only way to do a systematic study would be to keep some un-hashed passwords around and compare.
No, you could think up 20 different plausible "common mistakes", add fixes for those and roll out to some subset of users, and then just count the improvement rate of each fix to get the best four.
Actually, you don't have to keep unhashed passwords around. You can just return the wrong password in a hidden field. When the form is posted, if the hidden field is set, you can do some analysis. This might involve storing some 'intermediate state' of the Levenshtein algorithm, for example, to find the shortest edit distance. You would only store that information anonymously, without storing the passwords. (I'm not saying they do this, that's just of the top of my head.)
Edit: Or just keep the (wrong, correct) pairs for users where correct is in the top 20 most common passwords.
I noticed this issue on Wellsfargo as well. I did some research and learned it is due to being backwards compatible with phone banking. No shift key on the telephone.
password is not case insensitive, it looks to me that they store 4 password version (one for each variant) so they check both 4 in parallel to see if there is a match, it is not bad, it will be worst if they have the password in clear and they see if the inputted one match the stored one in one of the 4 variants (calculated on the fly) that will be bad because means that the password are in clear text somewhere :(
Why store 4 versions? They just store the hash of the correct one and try hashing up to 4 versions of whatever you enter. As soon as one of those corresponds to the hash, you're in.
[+] [-] zaroth|9 years ago|reply
You don't have to wonder if it "seems like going to far" because you can calculate almost exactly the reduction in the search space / entropy.
But don't just go based on the theoretical key space reduction. You have to look at the kinds of passwords that people actually choose and see if an online attack which gets on the order of 10 tries against a password before an account is locked would actually be marginally more effective because each submission is technically trying 4 passwords instead of 1?
The reality is the 4 additional tries that Facebook is giving you for free are not passwords that would be in the attacker dictionary in an attack which is allowed only 10-100 tries.
Whereas the 4 tries are probably at around 1% of the time, in other words billions of logins per year, result in a valid login for a user who knows the right password but simply failed to type it correctly.
Another key point to consider is if you give users these 4 extra tries for free on each submit, you cut down drastically (power law on the types of errors that users make) on the number of failed login attempts overall. When this happens you can now reduce the account locking threshold without catching a larger percentage of your real users in the "your account has been locked" trap. This results in a significant net improvement for security against online attack.
[+] [-] blueplanet200|9 years ago|reply
Facebook isn't giving an additional "try" by storing the password with caps lock. It instead reduces the search space by 26 characters.
Take for an example a password someone might have -
'AaaAaAaaAAaaaaaAaaAaAaaaAAaAaAaAAaaAAaAaAaAaaAaa'
If an attacker knew it consisted of only [A, a] at random it would take 2^50 guesses. But now it only takes a single guess, just all A's. It's a toy example, but Facebook definitely isn't just giving four extra guesses for free.
[+] [-] tgb|9 years ago|reply
[+] [-] ogdan|9 years ago|reply
[+] [-] sp332|9 years ago|reply
[+] [-] _nalply|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] tclancy|9 years ago|reply
That seems the strangest of them all: "If the login fails, try stripping a character off the end and see if that matches". I can understand the "First character inadvertently capitalized one" somewhat, but the CAPS LOCK thing seems unforgivable. I just did that yesterday with Apple and it simple suggested to me caps lock might be on. If your test for that is (password didn't match AND all alpha characters in the submission are capital letters) you don't even need to store a second hash for it.
I know there will always be trade-offs between security and UX but, if this image is accurate, that seems like going too far in favor of usability. No matter how small, multiplying the numerator in the probability of matching a password is a dangerous decision.
[+] [-] nn3|9 years ago|reply
[+] [-] semi-extrinsic|9 years ago|reply
[+] [-] beejiu|9 years ago|reply
Edit: Or just keep the (wrong, correct) pairs for users where correct is in the top 20 most common passwords.
[+] [-] joatmon-snoo|9 years ago|reply
Could also be some keylogger thing.
[+] [-] bluedino|9 years ago|reply
[+] [-] hk__2|9 years ago|reply
[+] [-] rijoja|9 years ago|reply
[+] [-] elbrian|9 years ago|reply
[+] [-] develprofthngs|9 years ago|reply
[+] [-] adders|9 years ago|reply
https://twitter.com/HSBC_UK_Help/status/579661876017139713
[+] [-] giarc|9 years ago|reply
[+] [-] zwerdlds|9 years ago|reply
At least in this thread, people seem to be giving FB the benefit of the doubt on that particular anti-pattern.
Can anyone rule out plaintext storage?
[+] [-] thatwebdude|9 years ago|reply
[+] [-] saltedshiv|9 years ago|reply
[+] [-] duke360|9 years ago|reply
[+] [-] Biganon|9 years ago|reply