You don't even need that. When you receive the password, you can compare the stored hash against:

  hash(password)
  hash(password-inverted)
  hash(password-first-upper-case)

This way it'll work with an inverted password even on the first attempt (after this feature was implemented)

Edit: Going by my gut feeling only, this feels slightly more secure too... If the hashed password database is ever leaked, it feels like it would be easier to crack a password given the three related hashes, compared to just the one.

I don't think that is correct. They'll need to generate and store hashes of all three variations on the plaintext password before discarding it. For example, given a password of "AaAaAa", where the user attempts to log in with "AAAAAA" (doh, capslock!), how would they guess which characters you intended to be uppercase and which not?

With capslock on the password would be entered as 'aAaAaA' (which would pass) not 'AAAAAA' (which would fail). There is no guessing, it is just the inverse.

That's a very Windows-centric view. On OS X, caps lock + shift is still uppercased.

Facebook only accounts for accidental Windows caps lock, not OS X.

Accepting the entirely uppercased password would significantly reduce the number of unique passwords needed to guess a user's password.

Also, while caps lock + shift is still uppercased, caps lock has no effect on the non-alpha keys. Indeed on a Mac, caps-lock is not shift-lock, it's literally caps-lock: on my French layout, caps-lock'd & gives &, not 1. Since keys with diacritics and other marks like é è à ç adn ù are first-class keys on a french layout, they themselves are capitalized by caps-lock, and not giving in to the shift behavior (which would yield 2 7 0 9 and %). This allows to type É È À Ç and Ù without composition.

If you want the caps-lock-gives-numerics behavior you need to set your layout to "French — numerical" — its icon is a french flag with 123 at the bottom — instead of simply "French".

Wow, that strikes me as strange. Windows and Linux both shift to lowercase when capslock is on.

Does anyone know the behavior of other operating systems? Or is it an Apple-specific behavior?

Actually, a Linux-centric view. :) I thought Apple removed the caps lock key a long time ago...

Thats weird! I had always assumed that Shift+Caps Lock is lowercased in all OSes.

Wouldn't it be:

    hash(password)
    hash(password-inverted)
    hash(password-first-lower-case)

The first character upper case-case only matters if the first character of the entered password actually is received in upper case, in which case, you'd want to flip it to lower before doing the hash, right?

Yes, obviously, sorry. :)

Given hash(password), how do they get hash(password-inverted)? That requires going from hash(password) -> password -> password-inverted -> hash(password-inverted), right?

I think that first step (un-hashing) is impossible for a cryptographically secure hashing algorithm.

Edit: archivator explained it me :)

0x0 is saying that when you receive the password you can do 3 checks. No need to invert the hash function there.

Also, inverting a hash function is impossible (the size of the range is less than the size of the domain). Finding a collision, on the other hand, is not.

Ah, yes. Of course, thank you.

Facebook's servers get to see your plaintext password for a fraction of a second every time you log in. That's their opportunity.

Hell, wasn't Zuck infamous for using the mis-entered password of users to break into their email accounts at Harvard?

Even if that tale is apocryphal, the underlying moral is true - your security is greatly undermined if you reuse your password (or key) across sites - any malicious site operator (or even an honest one that has their security broken) will expose you.

Thanks for asking this. I was confused too.

Ouch. Of course, that's way better.

I don't understand. So, you type in your password, and this input is sent (securely?) to their server, where it is hashed, and this hash is checked against their stored hash. But they can also "capture" this password prior to it being hashed? But then Facebook could do a few string manipulation operations, and then securely delete the un-hashed password from memory. Am I understanding this correctly?

The password is sent from your browser to the server in a way that the server can read it as cleartext. When you log in over SSL, all that does is protect your password (or whatever) from being interpreted by third parties.

Your browser doesn't do any hashing, it doesn't (and shouldn't) know about whatever password hashing scheme is happening on the server.

This is how sites can (but shouldn't) store passwords in clear text, because that's how they get them in the first place.