Passwords For Your Facebook Account | Hacker News Reader

Passwords For Your Facebook Account

labnol.org

155 pointsheroic64 comments

Ignoring the security implications for a moment, this is a very nice UX enhancement, I do imagine that it would eliminate the vast majority of the invalid password attempts thus making people's experience much better.

Now, the question is, just how much security are you losing by allowing this? Assuming the passwords are stored correctly my guess would be that passwords that are considered secure already would only be marginally less secure because of this, however non secure passwords (common ones) are a hell of a lot less secure but only in a relative context, they're still just as insecure as the original insecure password.

I'm not sure I articulated this properly so if I didn't let me know.

I'd say half the possible combinations are gone, minus one. I don't think that's too bad.

And I agree it's a great UX enhancement. I've been frustrated many times entering usernames and passwords with my phone defaulting to capitalising the first letter.

Now if only they'd strip # from the end of posts again (on UK keyboards at least it's right next to the return key, so many posts end up looking like this#

> half the possible combinations are gone, minus one

So, slightly more than one bit of entropy lost?

Most insecure passwords don't use mixed case anyhow (dictionary lower-case words), so I fail to see how this is making them much less secure.

In fact in terms of relative impact, this has a much greater impact on "secure" passwords (in this case, I mean ones that are a random jumbled set of mixed case letters and numbers). That's only really because it significantly reduces the range of the first character.

I would also argue that the security implications of this are largely positive. It removes less than two bits of entropy even from a randomly generated password, but it means that users reset their passwords less often, and I would guess that when users reset a "forgotten" password, they usually choose something weaker (and thus more memorable).

Does Facebook ask to prove yourself with another form of auth if you're logging in from an unusual place? I want to say it does, but I can't recall for sure.

I'd like to note, their assumptions on caps lock does not apply to Mac. If you hold shift while caps lock on a mac, it still gives uppercase.

Of course, if they implemented this, it would turn it into a case insensitive password with much bigger security implications. So, this isn't a criticism of their decision. Only an observation.

This raises several questions:

Have they always done this, or is this new?

For those of us who haven't changed our Facebook password in years, does this mean that we don't get this option, or do we? And if we do, is Facebook storing our passwords in plaintext?

They dont need to store your pasword in plaintext for this, but it does raise a security concern. 3 times the chances to have your password guessed by brute force!

Given a reasonably sized keyspace (which FB does have) a factor of three should not be a big deal.

You are right, but given the fact that most people still use very common words for their passwords, a 3 times increase is a very huge number. A recent story on HN stated the fact that passwords from sites that had their databases leaked, mostly consisted of dictionary based passwords.

One could posit that the negative security impact on such a password is negligible, since the password is already weak.

I think it would be worrisome if there weren't protective measures already in place, such as limited login attempts, two-factor auth, and so on.

The other weakness would be the repetition of that password on sites that place a low priority on, or are ignorant about, security. At which point, it doesn't even matter.

It's actually much more than 3 times the chance; this rule allows you to restrict your brute force search to only check passwords with no uppercase characters (or no lowercase characters) which reduces the key space for a given maximum password length quite a bit. (e.g., if there were normally 100 characters allowed and n is the max length, taking out 26 characters reduces the search space from 100^n to 74^n - not that an intelligent password cracker would ever try to iterate straight through the actual space of all allowable passwords)

Read the article again, its not making the passwords case insensitive, merely allowing you to invert the case. i.e. if your password was "aSdf" neither "ASDF" nor "asdf" would work.

Well I feel dumb, sorry. I thought he meant original casing + all lowercase version + all uppercase version were all acceptable (which isn't the same as case insensitive but for the purposes of cracking it is just as bad).

If you don't use Windows you definitely shouldn't feel dumb: if caps lock is enabled on Windows shift will cause you to type a lower case letter, thus inverting what you intended to type rather than uppercasing everything.

I was confused until I realized the caps lock case only applies to Windows users.

Actually, caps lock + shift gives lower-case in ubuntu as well.

I've been using OSX as my primary OS for about a year (other than using Linux exclusively on every machine I SSH into for dev), but I just found out from your post that caps lock + shift doesn't make things lowercase on Mac. So, nope, I have no excuses :P

That's not necessarily true -- it doesn't allow you to eliminate all uppercase // lowercase situations. You still have to have the correct casing, just inverted (as though Caps Lock was on). Since my FB password has both uppercase and lowercase letters, the inverted case would still have uppercase and lowercase. There is no option that I can use for my current password that is all lowercase or all uppercase.

I think we can be pretty certain Facebook already has robust login attempt throttling systems in place.

They are probably still storing hashed passwords. It would require hashing your login attempt 3 times: 1) exactly you typed it 2) forcing first character to be lower case 3) inverting the case of all letters.

You don't need to store the password in plaintext, you can just capture the password from a successful login attempt and generate new acceptable hashes from different variations of it. That way you'd gradually add this feature for most of the active accounts.

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.

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.

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

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.

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?

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

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

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

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.

You don't need to have the user change their password to implement this kind of change -- you can generate and store the additional hashes after any successful login attempt.

Rather than asking questions I tried some science. Last time I changed my FB password was roughly 6 months ago and I am only able to get the correct-case password to allow access. I'm not too inclined to spend much more time on this but surely someone who hasn't changed their password in a while can try it out. They can see if the alternate casings work, change their password and see if they work then, etc.

There's a nice article about this on the AgileBits blog [1]. In summary they say it's a net gain for security because trying variations on a supplied password doesn't help an attack much and reducing the number of password resets is a positive from a security perspective.

[1] http://blog.agilebits.com/2011/09/13/facebook-and-caps-lock-...

While obviously Facebook will be storing this as hash(normal), hash(upper(normal)), and hash(lower(normal)), there's an interesting security benefit to storing this in 3 columns, 'password1', 'password2' and 'password3'. The trick then is to randomise which hash gets stored in which column, i.e., password1 doesn't always correspond to hash(normal).

The slight benefit of this being that if your database is leaked, then the attacker won't have his/her brute forcing job made easier by knowing that the password3 hash only contains lowercase alphanumeric characters.

Edit: Apparently I suck at reading, it's not upper() and lower(). Woops :). Well, if any other sites do store upper() and lower() variations, I wonder if they use this idea?

It doesn't really provide much extra security. The factor of 3 slow-down it provides (having to check against three columns instead of one) is a small constant factor in the exponential task of brute-forcing.

I don't think they store three hashes though. Just the original one and they check against that. Only if that fails they proceed to verify other variants. There are only two - first letter uppercase (presumably for stupid phones) and inverse password (for caps lock on PCs). Both of these variants are reversible (i.e. you can revert the change to get original the password).

You can also login with your profile name, which I didnt know until very recently when I mistakenly dropped the @domain.com and was initially surprised to find it worked.

That only works if you actually change your profile name to something meaningful like facebook.com/yourname. A lot of people don't do that (they have an autogenerated id) and in that case the email is mandatory. I should also note that you can only change your profile name, i.e. facebook.com/profilename, twice. That is, going from something like facebook.com/profile.php?id=34534643 to facebook.com/profileName1 to facebook.com/profilename2. After that Facebook won't allow you, for some reason.

Also, phone number works too if you have it listed (possibly cell-only).

Also, I just noticed this evening that Facebook explicitly notifies you of incorrectly using your old password. Not sure how long far back they go to check.

The question is, what IS the value of the true password? How do you define "something and its inverse?"

I don't think I follow. What is the question?

(To get inverse password you simply reverse the case on all letters.)

I mean that while facebook prompts you for a password in a single field, if you enter "passWORD" the true value of your password is both "passWORD" and "PASSword", but there's no way to express that idea in the english language. If someone asked you what your password was, what would you say if you wanted to be completely accurate?

It's just a dumb philosophical thought I had.

One interesting observation from the comments:

On a Mac, shift with caps-lock on doesn't toggle to lower-case, so they would need to store a fourth version for this to work.

OPERATI@NGERONIMO

Overall it's a clever UX hack, though I worry they came to it by observing invalid password attempts which seems slightly outside of appropriate, although it doesn't particularly bother me in this case.

That would make all passwords essentially case-insensitive (all uppercase would work) and that would make it much easier to brute force than the inverted version.

True, and a good reason not to implement this solution.

My capslock key is backspace, so this feature is useless to me.

Reply on news.ycombinator.com