I've been playing around with different login forms online lately to see how they work. One of them was the Facebook login form. When I logged out of my account my email and password were autocompleted by my browser. Then I decided to misspell my email and see what would happen if I tried to log in.

To my surprise I logged in with no problem after changing my email from example@gmail.com to example@gmail.comm. I then started experimenting with different spelling errors and I had no problem logging in as long as it was not too far off my real email. I tried changing the domain name as well example@gmadil.coom, my email prefix ezfxample@gmail.com etc.

Then I also tried misspelling my password and as long as it was not too far off my real password I could log in no problem (with the password it worked when adding one random letter before or after the real password, but not when adding a letter in the middle of it).

I also checked the actual data sent in the request by looking at it in Chrome DevTools and in fact it was the wrong data sent.

How can this be? Should I be worried about my account's security?

  • 48
    If true (and it's a big enough claim that I'm going to want to verify it independently), then yes, everyone should be worried about account security, as it means passwords are stored in a reversible form.
    – Ghedipunk
    Aug 6 '19 at 21:33
  • 19
    @Ghedipunk to be more precise, it worked with a single random letter added before, and after the real password. Adding a random letter in the middle didn't allow me to log in.
    – aMJay
    Aug 6 '19 at 21:37
  • 70
    That's an important distinction, with the random letter being before or after (and thanks for editing the question with that clarification as well; it helps)... That can be checked without storing it in a reversible form. With them allowing a bit of a fudge factor like that, it's time for me to generate an even longer password, though... ;-)
    – Ghedipunk
    Aug 6 '19 at 21:43
  • 33
    It just decreased the entropy by a few bits. Aug 7 '19 at 6:25
  • 9

Facebook is allowing you to make a handful of mistakes to ease the login process. A Facebook engineer explained the process at a conference. The gist of it is that Facebook will try various permutations of the input you submitted and see if they match the hash they have in their database.

For example, if your password is "myRealPassword!" but you submit "MYrEALpASSWORD!" (capslock on, shift inverting capslock). The submitted password obviously doesn't match what they have stored in their database. Rather than reject you flat out, Facebook tries to up the user experience by trying to "correct" a few common mistakes such as inserting a random character before or after, capitalizing (or not) the first character, or mistakenly using capslock. Facebook applies these filters one by one and checks the newly "corrected" password against what they have hashed in their database. If one of the permutations matches, Facebook assumes you simply made a small mistake and authorizes your session.

While worrying at first glance, this is actually still perfectly secure for a few reasons. First and foremost, Facebook is able to do this without storing the password in plaintext because they are transforming your provided (and untrusted) input from the form field and checking if it matches. Secondly, this isn't very helpful for someone trying to brute force the password because online attacks are nigh impossible thanks to rate limiting and captchas. Finally, the odds of an attacker/evil spouse knowing the text of your password and not the capitalization are abysmally small and so the risk created as a result of this feature is equally small.

Should you be worried? No, probably not.

Further reading: https://www.howtogeek.com/402761/facebook-fudges-your-password-for-your-convenience/

    – Rory Alsop
    Aug 15 '19 at 12:44
  • 9
    It would help to know this when creating a password. For example, this at least appears to make capitalization useless/irrelevant insofar as security, so you may as well not use it - which saves a bit of brainspace. Oct 5 '19 at 14:49
  • 3
    @ChrisMoschini unless you only capitalize the first word - I completely disagree. As is explained in the answer, facebook tries the password with inverted capslock, so, taking from his example, if you send "myrealpassword" or "MYREALPASSWORD", it won't work. Oct 12 '19 at 0:47
  • Also worth noting that Facebook employs multi-factor authentication by default. In this particular implementation, the online attack resilience of the password isn't as important as it would be in a vacuum. Oct 16 '19 at 16:34

It is long know that Facebook allows you on purpose to log in with the password case reversed or the first character capitalized (see this article). They do this while storing only a hashed password. Are you seeing that more differences are allowed?

Apparently, they also have some similar usability features for the email address. Automatically "correcting" gmail.comm to gmail.com is actually harmless, since there's (currently) no comm tld, so nobody would actually have a valid gmail.comm email address. I am however surprised that they would allow gmadil.com (currently for sale) or a different username, as that could be someone else's email address.

They might have decided that usability is of utter importance and, if there is a log in attempt for an email address for which there is not an account, automatically attempt the log in with the most similar username, but -while not completely bad- it doesn't seem a good approach, as someone else could sign up tomorrow with the ezfxample@gmail.com email and, although unlikely, also use Password123 as password, then what?

Update: This had been tested a few years back by Lukas on Does correcting misspelled usernames create a security risk? and apparently logging in with a misspelled email address only works when you have not deleted Facebook cookies from your earlier session. Thus, it only autocorrects your email address when it knows that you used to log in as example@gmail.com, and otherwise fails.

Note: Another user had suggested earlier that the cookies could be playing a part of this, but it is now in a deleted answer.

  • 1
    gmadil.com isn't actually for sale. It is a malvertising domain here in Belgium.
    – Nzall
    Aug 7 '19 at 9:07
  • 54
    "They do this by storing the different hashes of the password" - Citation needed. I think it is much more likely they take the plain text of the provided password, hash that and check if it is the the stored hash, then invert the case of the first letter, hash that, and check, etc. Storing multiple hashes would make brute-forcing much easier if the password database leaks (because an attacker can hash once, and compare against multiple values). Aug 7 '19 at 10:55
  • 13
    Besides @MartinBonner's objection, storing multiple hashes would also make it much more complicated to implement changes to the algorithm by which the set of password variants to allow is computed - since it wouldn't be possible to compute any new hashes, or to determine which ones to remove, until the user next logs in and provides their password. Just hashing all the possibilities on the fly, while presumably carrying a very mild performance cost, is much more straightforward to implement.
    – Mark Amery
    Aug 7 '19 at 15:29
  • 2
    @MartinBonner (and @MarkAmery): Fair point. I wanted to note that they didn't store a plaintext password for that, but there are multiple ways to achieve it. I have edited the answer to make the statement more open.
    – Ángel
    Aug 7 '19 at 20:50
  • 2
    Yes, there could be a matching username at a similar address, but unlikely the owner of such an e-mail address also happens to match your password. (Unless of course you both used a common insecure password.)
    – WGroleau
    Aug 7 '19 at 23:59

If you consider the login process as a whole, this measure can actually increase security. Instead of granting users several login attempts to manually fix common misspellings, the site tries to fix those misspellings automatically. As a result, the average number of login attempts a user needs goes down, which means a more strict rate limiting to an attacker who tries out various common passwords, not slight variations of the same password.

  • 6
    You have perhaps overstated your case. This process helps to identify truly random brute-force attempts.
    – schroeder
    Aug 21 '19 at 11:09
  • 1
    @schroeder Sorry, I didn't get that. Fixing common misspellings means less login attempts before rate limiting. Rate limiting prevents password guessing, both brute force and dictionary based. Mitigating password guessing improves overall security. Aug 21 '19 at 11:36
  • 4
    This does not mitigate all password guessing, it mitigates a certain approach to password guessing. So, I'm not sure you can go so far as to say that it improves overall security.
    – schroeder
    Aug 21 '19 at 11:38
  • 3
    @schroeder Statistical data would be required to prove whether it actually improves security or not. And of course there will be no improvement if the rate limiting is not made stricter. All I'm trying to say is that security can be increased with such a measure. Aug 21 '19 at 12:26
  • 4
    @schroeder would it not also require less attempts at guessing a password, thus decreasing security?
    – Hearth
    Oct 4 '19 at 2:02
