Often I see it being discussed that if configured and enabled, 2FA will increase the security of an account, it will add an additional security layer, however an attacker could still gain access to the said account somehow.

Considering the scenario: I have 2FA configured in my GitHub account, and I use the Google Authenticator app.

If the attacker had my account’s password (keylogger on my computer or similar attack), how it would be possible to go through 2FA without physical access to my phone?

  • potential duplicate: security.stackexchange.com/questions/106628/…
    – schroeder
    Dec 3, 2018 at 11:02
  • 1
    Hi Filipe! Could you add a citation to the claim that it's not considered flawless, so we can give you a better answer?
    – Cowthulhu
    Dec 3, 2018 at 14:37
  • By qualifying your question with "without physical access to my phone" you're already removing a whole bunch of possible attacks from consideration. Why wouldn't you consider someone stealing your phone a possible "flaw" in this system?
    – Ajedi32
    Dec 3, 2018 at 21:31
  • If the attacker has stolen my phone - and gained access to it somehow - the whole point of the question is already answered. Dec 3, 2018 at 21:48
  • Many times the "weakest link in a chain" is the user: Just imagine a user performs an unencrypted backup of the 2FA device on some cloud storage... Or the primary password manager also includes the 2FA secrets (as a "backup"), the password manager has a weak password, and the database gets disclosed somehow (like USB stick being stolen).
    – U. Windl
    Dec 27, 2023 at 11:06

3 Answers 3


Well, I hate to break this to you, but Google Authenticator plus password isn't really two-factor authentication. Proper 2FA is two separate items out of traditionally the triad "something you have" (physical item, which may itself hold a secret), "something you know" (secret), and "something you are" (often biometrics).

Password plus Google Authenticator is probably better summed up as password and soft token, as Troy Hunt did in a recent blog post. Basically, the app stores a secret, and uses that secret to generate temporary passwords.

If someone is able to break into your phone general-purpose pocket computer with a variety of radio interfaces running arbitrary, potentially hostile, software, they could presumably find some way to extract those secrets. Once extracted, they could likely be transplanted onto a different phone, which would now generate the same temporary passwords.

This doesn't mean that a "soft" 2FA is meaningless. It does raise the bar considerably for an attacker. But it's still a variation on "something you know"; only that the knowing part is done by your phone, rather than by your brain (or, hopefully, password manager).

To make a claim that something is "flawless" means that there must be, at a minimum, no conceivable way by which it could be exploited by an attacker. This seems a rather high bar to meet for a general-purpose computer running arbitrary software storing a high-value secret.

Better to just stick to saying that it makes an attacker's job more difficult.


Two-factor authentication methods that involve the user typing in a password into the website are still vulnerable to phishing attacks. If you accidentally visit a GitHub impostor site with a similar URL and enter in your username and password into it, then the impostor site server can relay your username and password to GitHub, see the 2FA password prompt, show that to you, and then relay the 2FA password you enter into GitHub. Then the impostor site server will be logged in as you on GitHub and can do anything with your account. (The impostor site could even proxy traffic to GitHub, so the impostor site looks just like GitHub would if you were logged in. Or the impostor site might just redirect you to GitHub's login page and let you think you had logged in incorrectly.)

Two-factor hardware security keys that use the FIDO/U2F standards are immune to phishing attacks like this. When you connect and use a security key, your browser tells the domain of the site you're at, and the security key tailors its response based on the domain. So if you're accidentally at a phishing site with a URL different than GitHub's URL, then the security key won't give the same response that it does for GitHub, and therefore the impostor site won't have a security key response for GitHub to proxy to GitHub. (However, if the attacker was able to get you to connect your security key into a compromised computer or got you to install a modified browser, then the attacker could claim to the security key that their impostor site was GitHub.)


2FA doesn't do much to prevent MITM/phishing attacks.

Say I email you spoofing Github saying your account has been compromised, you click the link that takes you to git-hub.com, then you enter your account details on my server which my script will then enter on github.com. Then my website will prompt for your 2FA code which I will proceed to forward to Github, and you've successfully let me into your account with 2FA.

After this I will redirect you to github.com where you were still logged in and you'll have no idea you let me in.

If I was able to keylog your computer, this would be even easier as I could install an evil DNS and a certificate so navigating to github.com will take you directly to my site.

  • 2
    You are thinking of a specific form of 2FA, which you should probably mention
    – schroeder
    Dec 3, 2018 at 11:45
  • Some problems technically here. In your scenario, the attacker does not have access to the account. They get the password and one 2FA code. If the attacker hands the session over to the user, then the attacker loses control over the session and is locked out. Keylogging does not permit DNS changes or installing certs.
    – schroeder
    Dec 3, 2018 at 11:51
  • As mentioned by @schroeder this could work, but only for a specific scenario where it’s being assumed the victim will “fall” for a phishing attack. I’m curious about scenarios where the attacker already have access to the user’s password (password leaks or keylogger), how to bypass the 2FA layer? Dec 3, 2018 at 12:48
  • I mentioned a specific form of 2FA because the question mentioned Google Authenticator. Keylogging doesn't permit installing certs or DNS, but if a software keylogger is installed, a reverse shell can often be installed using the same vector. The other weakpoint in 2FA is that it almost always needs a way to be reset incase of a lost device. If a keylogger is installed and the email account can be accessed then 2FA can often be reset/enabled. If you're expecting a cryptographic flaw in TOTP, it doesn't exist. The implementation/user authentication is almost always the weak point.
    – three69
    Dec 3, 2018 at 12:59
  • Your answer makes general statements about 2FA when you should probably mention that you meant the type of 2FA used by Authenticator. Instead of saying "keylogger" then you could simply say "remote access malware". Keylogger is too specific a function for what you want to say.
    – schroeder
    Dec 3, 2018 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .