Hacker News Reader

Comment by tclancy | Hacker News Reader

>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.

View on HN

One additional character may be for "I fatfingered a key as I pressed Enter".

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.

They don't store separate hashes. If the password is wrong, they just flip the case of the input and try again. They do a similar thing with changing passwords, see this comment https://security.stackexchange.com/questions/53481/does-face...

How can they get away with not storing at least a second hash? I don't see how an all-caps password can be matched to an any cased password, unless you only store the hash to the all-caps password.

It's not all-caps, it's typed with caps-lock down (i.e., case inverted).

Note that this behavior is OS specific. Windows will invert case (shift gives lowercase), while macOS will be all-caps (shift doesn't do anything).

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.

Drafters (the guys who draw engineering drawings) love it because you very rarely but just enough have to type lowercase letters (such as units, like 3mm) whilst all other text must be in capitals. Thus, you just use shift to shift it to lowercase for those rare moments and no other times.

Thanks! Case inverted makes sense. They can invert the case before hashing and submitting. If any of the four hashes match the stored hash, they get in.

I think what was meant was that they don’t store a second hash in order to allow chopping off a character at the end. I agree with you that they would need to store extra hashes for allowing all-caps and some of the other cases.

No extra hashes needed for an all caps version or inverted case version of a password, just perform those transformations on the user input, hash, and compare the result to the single stored hash.

> That seems the strangest of them all: "If the login fails, try stripping a character off the end and see if that matches".

Not really.

(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.

Reply on news.ycombinator.com