554

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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
aMJay
  • 3,615
  • 5
  • 11
  • 20
  • 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 06 '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 06 '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 06 '19 at 21:43
  • 33
    It just decreased the entropy by a few bits. – Peter - Reinstate Monica Aug 07 '19 at 06:25
  • 7
    Can you reproduce this after deleting cookies, localstorage, and other storage? Or try it with a fresh browser profile. I suspect, that your username could still be stored in a cookie and facebook only tries to verify if you want to login to the account in the cookie, so they can accept minor differences, because they only need to detect if you want to use another account, but not what's the username of the current account. – allo Aug 07 '19 at 09:13
  • 9
    Related: https://security.stackexchange.com/q/122848/59741 and https://security.stackexchange.com/q/68013/59741 – Andrew T. Aug 07 '19 at 12:31
  • 4
    It's worth adding that Facebook allows 2 factor authentication which vastly improves the security of your account – 99 Problems - Syntax ain't one Aug 07 '19 at 15:43
  • 8
    Highly related and/or duplicate: [Facebook password lowercase and uppercase](https://security.stackexchange.com/questions/68013/facebook-password-lowercase-and-uppercase) – MonkeyZeus Aug 07 '19 at 16:34
  • 5
    Would be interested to see what happens when you create an new account with a very similar email prefix. – zr00 Aug 08 '19 at 17:09
  • 4
    Unless you're officially participating in one of Facebook's security bounty programs, you need to be very careful (i.e. stop it now) probing Facebook for security vulnerabilities. In general you should not probe other people's websites unless you've thoroughly covered yourself legally; otherwise you could run afoul of laws prohibiting hacking, and do so in a way that could land you in prison for quite a while. Here's an example: https://nakedsecurity.sophos.com/2012/02/20/jail-facebook-ethical-hacker/. Will look for a more extreme example... – bob Aug 09 '19 at 18:57
  • 3
    Can't seem to find the other example; basically a white hat hacker was sentenced to prison time for entering a single-quote in a form on a public website as this was interpreted in court to have been an attempt at a SQL injection attack. Bottom line: do NOT assume that your actions will be taken as harmless. – bob Aug 09 '19 at 19:00
  • 1
    Okay here's a link to a Quora answer that addresses some U.S. legal implications (note: IANAL) of probing the security of someone else's website: https://www.quora.com/Is-it-legal-to-test-a-website-for-vulnerability-without-permission-from-the-owner/answer/Kate-Vershov-Downing. And here's a SE Security answer that discusses this: https://security.stackexchange.com/questions/6355/at-what-point-does-hacking-become-illegal-us – bob Aug 09 '19 at 19:06
  • 2
    And finally, here's a case where someone wanted to make sure the site they were using was secure so they probed its security and got convicted of a crime in the process (and got fired): https://www.theregister.co.uk/2005/10/06/tsunami_hacker_convicted/. So unless you're part of their bounty program or you have been hired by them as a security researcher, you really need to stop probing their security immediately, for your own sake. No sense in going to prison for being smart and creative; better to find a safer route to satisfy your curiosity. – bob Aug 09 '19 at 19:13
  • @99Problems-Syntaxain'tone AFAIK Facebook's two-factor authentication forces you to allow SMS 2FA – simplegamer Aug 15 '19 at 17:04
  • 1
    @bob but a single quote could be trying to find a hole. MIsspelling your email address with them correcting it is clearly functionality they designed. Surely you could never go to prison for misspelling your email address. Unless you misspell it with a SQL injection. And aren't these companies mad for pressing charges, they should talk to you and allow you to help. All they did was avoid the issue by putting someone in prison. It would be better to say "what did you find". – Eoin Oct 02 '19 at 12:19
  • 2
    @Eoin I agree that everything you say is logical. Unfortunately it seems like law and logic don't always intersect (IANAL), plus I can see where a company might want to discourage unsolicited penetration testing from people outside the company, and prosecution is unfortunately an effective way to do that (not saying that's why charges were brought in these cases, just saying why I think they could have been brought). So I'd be very careful to avoid behavior that might get flagged as a possible hacking attempt. Just my two cents. – bob Oct 02 '19 at 12:51
  • 2
    And everything I've seen written by security professionals online basically says the same thing: never probe security without permission and adequate legal protection (the latter means a documented legal agreement, and perhaps even some form of insurance if something does go wrong). Because in cases where it makes zero sense to do so, charges can be pressed, and you could lose the case and end up in prison. So I'm basically just repeating that advice here. – bob Oct 02 '19 at 12:53
  • If you don't need to take the risk, don't take the risk. Although this information is also in the public, so you definitely don't need to take the risk as they have declared it. – Eoin Oct 02 '19 at 13:11
  • @simplegamer my Facebook account uses app authentication (google's authenticator), so it doesn't force SMS 2FA – Ng Oon-Ee Oct 03 '19 at 02:10
  • @bob dear gosh what if your finger slipped and you hit a single quote by accident without realizing it?! what if your cat ran over the keyboard and submitted the form? – Michael Oct 03 '19 at 17:29
  • @Michael Absolutely. Things happen, my main point is just don't do security probing if you don't have permission because you're liable to raise red flags and could get in a lot of trouble. If you're just using the system and accidentally type something weird once, you're probably fine. If not, then laws need a *serious* overhaul. But in general unsolicited security probing isn't a good idea. Not my words--I encourage you guys to check what I'm saying online. – bob Oct 03 '19 at 17:33
  • See related old question https://security.stackexchange.com/questions/53481/does-facebook-store-plain-text-passwords – Michał Šrajer Oct 06 '19 at 13:06

3 Answers3

635

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/

Filipe dos Santos
  • 1,090
  • 4
  • 15
Allison
  • 3,975
  • 2
  • 13
  • 19
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/97458/discussion-on-answer-by-sirens-why-can-i-log-in-to-my-facebook-account-with-a-mi). – 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. – Chris Moschini Oct 05 '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. – Cássio Renan Oct 12 '19 at 00: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. – Monica Apologists Get Out Oct 16 '19 at 16:34
83

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.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • 1
    gmadil.com isn't actually for sale. It is a malvertising domain here in Belgium. – Nzall Aug 07 '19 at 09: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). – Martin Bonner supports Monica Aug 07 '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 07 '19 at 15:29
  • @Nzall: here gmadil.com redirects to ww1.gmadil.com, which is parked by Sedo (resolves to 91.195.240.34, owned by Sedo) – Ángel Aug 07 '19 at 20:46
  • 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 07 '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 07 '19 at 23:59
  • @MartinBonner doesn't the same logic apply to something like a dictionary attack, where they only need to get the password "close enough" for this system to match a variation that results in the correct hash? this strikes me as exceedingly risky for such a public site (obviously they would have other defenses for multiple login atempts etc, but still.) – Hearth Oct 04 '19 at 02:00
  • @Hearth Not really. There are two sorts of attack. Online attacks are completely mitigated by rate limiting and lock-out. Offline attacks mean that someone has got hold of a copy a Facebook's database (which is bad). Assuming a competent design, the attacker will have to hash each candidate password (with the correct salt) and compare with the stored hash. This was actually my point; if FB stored multiple hashes, the attacker can hash "password", and check for "Password" too. – Martin Bonner supports Monica Oct 04 '19 at 07:26
28

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.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
  • 7
    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. – Dmitry Grigoryev 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. – Dmitry Grigoryev Aug 21 '19 at 12:26
  • 4
    @schroeder would it not also require less attempts at guessing a password, thus decreasing security? – Hearth Oct 04 '19 at 02:02