Despite not using the site anymore, I appreciate how facebook handles this. If your password is incorrect, it checks again with the case swapped to account for caps lock being on.
No, if CapsLock was set to on when you pressed the key, getModifierState('CapsLock') returns true. It is true that this doesn't let you query the caps lock status directly at will, instead you have to wait for a keyboard event. But it is not merely telling you that Caps Lock itself was pressed, rather that a key was pressed while CapsLock was enabled.
This is exactly how it's working for me as I test it on this textarea.
So if you wanted to add one of those "Hey, Caps Lock is on" warnings to a password field, you could do so, you'd just have to wait for the first key to be pressed.
I love this idea, going to add this to future projects.
It means that the passwords have far less entropy.
It means the uppercase you password when generating a hash. Good lord.
And for weak passwords... Well, it's not like that one extra bit would have made a difference.
Also, can someone please tell me that Facebook doesn't really do this?
It exchanges a few bits of entropy for a much smoother user experience, and it doesn't actually aid an attacker much (they could just try the permutations themselves)
Obligatory XKCD: https://xkcd.com/936/
Don't forget that the shift key makes things lowercase when Caps Lock is turned on.
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-...
- User types pA$$WORD1 and clicks Sign In
- Frontend sends that to the server
- Server responds "incorrect"
- Frontend tries again with Pa$$word1
- Server responds "correct" and user is logged in
You either have to double the number of failed attempts before a lockout or deal with users getting locked out much quicker.
Thus causing more frustration than if you'd done nothing at all to address the capslock issue (that they're going to have to notice and fix anyway at some point, when they inevitably need to type again)
No it doesn't. Say your password is "Abc1". When you sign up, they would hash "Abc1". Then when you login, say you type "aBC1". The site would first hash "aBC1" and find that it is incorrect. Then it would invert the case to "Abc1" and try again, and it would work. It's basically just automating a second attempt. In fact, I wonder if it even counts as a second failed attempt if both failed.
If someone were able to make brute force attempts on the website, it would still end up evaluating the passwords the same number of times as if the inverted case wasn't checked (the attacker would just need to invert it themselves) and in fact would likely slow down the attack because they are forced into checking inverterted case passwords. But that's moot anyway because the website limits login attempts. And if the database leaked, it's not stored any differently than if they didn't invert the case.
Of course I'm making assumptions about the implementation (I didn't know they did this until this comment) and it could be done poorly but I would hope a company as big as meta/Facebook put at least this amount of thought into it.
This makes more sense, and obviously a better idea.
0: https://en.wikipedia.org/wiki/Letter_case#Bicameral_script
Making it more convenient for everybody equally is an admirable goal, but should a trivial change that makes life a bit easier for many people be scrapped just because making it easier for everyone else is difficult? Specifically here where the experience doesn’t significantly regress for anyone.