Facebook and caps lock unintuitive security
by Jeffrey Goldberg on
It has recently been noted over at ZDnet that if your Facebook password is
PattyAndMolly, Facebook will also accept
pATTYaNDmOLLY as a valid password. This may initially seems look something that weakens users’ security. However it actually is a good thing.
Facebook designed their system this way to help people log in even if they have their Caps-Lock key on (or had it on when they created their passwords for Facebook). The Caps-Lock problem is remarkably common, and it’s not at all surprising that this is at the top of our list of things to check in our “I forgot my master password” document.
My over all point in this post (which I probably repeat too much) is that some times our intuitions about security run counter to what we find when we look at things more deeply. So let’s look at this case a bit more deeply and explore how it impacts security.
I assume that when a user enters a password that fails, the Facebook login procedure will retry with a modified version of what the user entered. That is, Facebook it really just trying again on behalf of the user, but it is trying as if the Caps-Lock key was set differently. If you give Facebook your password as
PattyAndMolly and that login fails, Facebook will immediately retry with
Of course 1Password users will be using strong random passwords for things like Facebook instead of passwords like
PattyAndMolly, but I will stick with this example to illustrate what is happening.
Lets return to what Facebook does when a user enters a password that doesn’t work. The Facebook login system will say to itself, “Hmm, the user gave me an incorrect password. Let me take what the user gave me and try again but this time pretending to press the Caps-Lock button first.”
Working with this assumption about how the Facebook login system works, we need to look at how Facebook’s policy might make things easier (or not) for an attacker. There are three cases to consider.
If someone captures Facebook’s database of encrypted passwords the attacker will be able to use his or her own system to have a go at cracking the passwords. This is called on “off-line” attack.
The database will have only one encrypted entry per user. And so a password guessing program will still need to try all of the combinations, including both PattyAndMolly and pATTYaNDmOLLY. This is because the underlying system is still only accepting one form of the password, even if the login system that a user interacts with takes a second guess.
We can see that in this case, the Caps-Lock transformation doesn’t weaken security.
If an attacker must guess at various passwords over the network by connecting to Facebook’s login mechanism, then before they can try more than a handful of guesses, Facebook’s lock-out and throttling mechanism will come into play. If you enter a password incorrectly too many times, Facebook will deliberately slow down (throttle) how many login attempts you attempt in a minute. It might even refuse to process any more login attempts (lock-out) and require that you go through a different login procedure.
So unless an on-line attacker is extremely lucky, throttling or lock-out will kick in long before any gain from the system trying multiple versions of the password can benefit the attacker.
There is a third possibility that we need to consider. Suppose that an attacker is able to get behind the throttling and lock-out system, but still tries to guess passwords using the remainder of Facebook’s system. That is they can query Facebook’s password checking system without having to worry about throttling or lock-out. Does Facebook’s transformation of failed passwords help the attacker?
The answer, again, is “no”. This will not help the attacker. This is because for every password the attacker tries, two passwords need to be checked. This doubles the checking time. It makes no difference to an attacker if it takes one second to check each of
pATTYaNDmOLLY, or it takes two seconds to check only one of those while having Facebook perform the second check for them.
Presumably Facebook using something like PBKDF2 and trying two passwords instead of one will have the effect of doubling the PBKDF2 iterations.
Again, in this third case we find that adding in the Caps-Lock transformation does no harm.
I think that I’ve covered why Facebook performing this kind of transformation (assuming it is implemented along the lines that I imagine) does no harm. But why is this good for security?
It certainly is a convenience for users who have mishaps with the Caps-Lock key. But the actual security gain comes reducing the number of password reset requests that Facebook needs to handle. Processing a password resets is fraught with difficulty. It often involves a secret (typically a link or a temporary code) being sent by email. The email can be intercepted or the user’s email account may be compromised.
Password reset requests really are a common way for attacking services like Facebook. So Facebook needs to check and audit those requests carefully. The fewer unnecessary password resets the easier it will be for them to spot malicious attempts.
There are two real downside to this policy that I see. The helpful Caps-Lock transformation can train users to be sloppy about case. That is, if users get too accustomed to things like this they may form the opinion that case doesn’t matter in passwords. I don’t see that as a big danger here, but there are other instances when training people to behave unsafely may be a very bad thing indeed.
One spectacular example of training people to behave unsafely is painting roads so that it appears that there is a person on them in a misguided effort to get drivers to slow down. Imagine what happens when drivers grow accustomed to these optical illusions and start adjusting their behavior.
In the case of Facebook’s treatment of Caps-Lock, we have much less to worry about. It is unlikely to affect the general behavior of many users. Still, we must always be mindful of the dangers of teaching people bad habits.
The other security downside to Facebook’s practice is that when users discover this, they tend to (incorrectly) perceive it as a weakness. Scared and panicked people make very poor security decisions in other places. This, by the way, is why we no longer use the same Caps-Lock mechanism for 1Password master passwords.
Facebook’s scheme is a bit more complicated than presented here. With login attempts from mobile devices they also will retry failed logins by changing whether the first letter of the password is capitalized. This is because many mobile devices will put in automatic capitalization, even where it gets in the way.
Also I should note that I have no inside information to how Facebook manages these things, and have taken some guesses about how things work. However, the kinds of designs that I’ve assumed have precedents. These aren’t wild guesses at how things work.
My main point, if you will forgive me for repeating it, is that security issues can be subtle — sometimes even counter-intuitive. We are always on the alert for ways that we can make the secure thing to do the same as the easy thing to do even if the underlying system is more complex.