[rezonant]

Whoa, let's not all freak out here (for this post and sibling posts). While I don't think I would personally do this, it only removes 1 bit of entropy because the case is swapped, and it only does that when checking the password. This does not imply they uppercase/lowercase the password prior to hashing at all, nor that foobar123 will work when the hashed password is FooBar123. Rather that fOObAR123 can be transformed by swapping case to FooBar123 and then checked against the hash.

Don't forget that the shift key makes things lowercase when Caps Lock is turned on.

[ryan-c]

It doesn't remove even a single bit of entropy.

For an offline attack, where you have to attack Facebook's bespoke "password onion"[1], you would still have to compute both hashes. There is approximately zero impact on cracking strategy.

There may be an argument to be made that Facebook would have otherwise used a larger work factor had they not had to do double the work for wrong passwords, but the common case is the password being correct, so I doubt this was a significant consideration in the parameter selection.

Even for the online case, I really don't think it affects security in a nontrivial way.

1. https://bristolcrypto.blogspot.com/2015/01/password-hashing-...

[rezonant]

I agree, for offline attacks there is no impact. Very interesting article. What is up with $\$$cur there btw? In PHP that would be a gnarly indirection-- even if it's something in FB's codebase, why keep it on the slide like that?