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.
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 -
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.
1) String with case inverted -- effectively undo capslock
2) String with first character lowercased, if it was uppercase
3) String with last character removed
EDIT: So it's actually 3 extra tries, not 4 extra tries.
Well don't I feel stupid. Didn't realize undo capslock meant inverting the casing. Doh.
> Note the title is wrong but the linked response from Facebook describes what they actually do quite succinctly.
And you still responded with this. Come on.
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.
You don't need to store a second hash for any of these; just transform the sent password with (invert all characters, invert one character, delete last character), rehash it and compare it to correct.
Whilst it does increase the numerator, it also allows Facebook to decrease the number of obviously wrong password attempts permitted before taking additional precautions. Since these are overwhelmingly likely to be user error, I think it's a perfectly reasonable tradeoff.
Frankly I can't remember the Windows approach ever being useful to me, and more often than not it bites me in the ass because I habitually hit something like shift-i to type "I" and end up with a lowercase i instead.
(The other ones aren't strange either, but I admit I have never heard of this practice.)
If you have the password stored in Notepad and there's a space behind it. Or you already have a space behind it, and then entered it. Or it is a DOS document you copy/paste from. Quite common. But I suppose the other 2 are more common.
Edit: Or just keep the (wrong, correct) pairs for users where correct is in the top 20 most common passwords.
Could also be some keylogger thing.
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?
My outside impression is that security is taken seriously enough at Facebook to hire highly competent people to run it. They pay out bug bounties, and run internal red team exercises to test their own ability to detect and react to a compromise. https://threatpost.com/how-facebook-prepared-be-hacked-03081...
I think we can extend them enough benefit of doubt to rule out storing user passwords in plaintext.
Edit: PCI compliance rules out plaintext storage so it seems unlikely.
It's worth noting that plaintext storage might not be the case if they store the fourth and only the fourth character separately at encryption time.