6 ms·

IANAE in identification & authentication systems, but doesn't using a browser plugin for the 'something you have' portion of 2FA negate the principal benefit —

• conorgil145 9y ago
  Sorry this is so long, but I felt it important to be relatively thorough. It sounds like there are 2 distinct attack vectors you are considering: malware installed on a trusted device and a local attacker gaining access to a trusted device. I'll define "trusted device" as any device which has a 2FA secret on it (e.g. phone, tablet, laptop, etc). MALWARE Malware on a trusted device is absolutely a legitimate attack vector and there are a few distinct scenarios to discuss. First, assume malware is on the trusted device before 2FA is enabled for a given service. In this scenario, the malware can obtain the 2FA secret directly anytime the user configures 2FA when the QR code is shown on the screen, etc. This is obviously bad, but also obviously out of scope for 2FB. Second, assume malware is only installed on the trusted device after 2FA is enabled on a given service. In this scenario, the malware will most likely not be able to get the 2FA secret from the service because most services only show the 2FA secret during configuration (good!). The malware can then only get the 2FA secret if it is stored on the same trusted device as the malware (e.g. what 2FB does). There are some approaches to reduce the attack surface in this scenario. For example, 2FB can encrypt the 2FA secret vault on the trusted device with a user provided password so that all 2FA secrets on disk are encrypted. The malware will now have access to encrypted data on disk that it will have to brute force. This is a similar approach to how Authy cloud backups work [1] and is reasonably secure assuming that the user provided password is strong. 2FB can individually decrypt a given 2FA secret at the appropriate point during the login flow so that the secret is only ever available in plain text in memory and for a short time period. This does not reduce the risk to zero, but it does significantly decrease the risk and increase the complexity of the required malware to obtain the plain text 2FA secrets. Also, users who are (rightly) concerned about malware on their devices will have the option to explicitly not treat the laptop as a trusted device (disable storage of 2FA secrets on their laptop). In this scenario, 2FB will send a push notification to the 2FB app on your mobile device each time that a 2FA code is required during the login flow. This behavior will basically be the same as Google Prompt [2]. However, whereas Google Prompt only works within the Google ecosystem, 2FB will work for any sites that 2FB integrates with (e.g. Google, Amazon, Microsoft, Github, Stripe, etc, etc). I realize that this is not mentioned at all in the screencast I initially linked to and you had no way to know about this (unless you’re a good guesser or read all of my previous HN comments). ATTACKER WITH LOCAL ACCESS This situation begs the question of what the actual threat model is for 2FA. I have been trying to track down an authoritative definition of the 2FA threat model, but cannot find one from a reliable source. (If you know of one in any academic papers, security white papers, etc, please share!). I think that the threat model for 2FA primarily includes a remote attacker gaining access to an account via a leaked knowledge factor (e.g. password). I do not think that 2FA is intended to prevent against local attackers or device theft in general. That being said, I am in strong agreement that separating the knowledge factor and possession factor as much as reasonable is a great idea. In practice, I believe this means that your password manager on your trusted device should be configured to auto-lock after X minutes of inactivity so that, in effect, it is only unlocked when you are entering a password in a web page. In this case, the knowledge factors are reasonably protected on the trusted device (assuming the master password for your password vault is strong) and could basically be treated as if they weren’t there at all because a local attacker would need to brute force the encrypted file to gain access to the passwords. Similarly, as mentioned above, 2FB can optionally encrypt the 2FA secret vault locally on disk. Also, a local attacker will likely not even need to steal your authentication factors at all to gain access to your accounts because they can just steal your active session cookies to gain access to your accounts. A security measure which is more intended to solve the local attacker/stolen device attack vector is full disk encryption. Any device with full disk encryption enabled with a strong password should be reasonably protected from a local attacker assuming that the attacker does not gain access to the trusted device while it is running and logged in as a user. FINAL THOUGHT One huge benefit of 2FB being a web extension is that it can help prevent a user falling victim to a phishing attack. During each login flow, 2FB can verify that a given web page is loaded over HTTPS with a valid cert and that the domain matches the domain for which a 2FA secret was initially configured. Only then will the 2FA code be injected into the page. 2FB cannot be tricked by pages that look like the expected site and are actually on some bogus domain. I am working on a security white paper to explain 2FB’s architecture and address the concerns you raised and several others. My email is in my profile if you’re interested in continuing the discussion, which I would find incredibly valuable! Finally, I am curious which specific portions of NIST 800-63B are you referring to in your comment? [1] https://authy.com/blog/how-the-authy-two-factor-backups-work/ https://authy.com/blog/how-the-authy-two-factor-backups-work... [2] http://www.zdnet.com/article/google-prompt-you-can-now-just-tap-yes-or-no-on-ios-android-to-approve-gmail-sign-in/ http://www.zdnet.com/article/google-prompt-you-can-now-just-...
  • zaarn 9y ago
    I think the most useful threat model for 2FA is the case of a leaked password. Malware on a trusted device or a local attacker are very hard to circumvent, though for that we have u2f which is reasonably safe against both. I put 2FA in my password manager for that reason. If I have malware on my PC, I'm pwned, there are plenty of services without proper 2FA (looking at you paypal, amazon and my email provider) that I can consider myself pwned. However, preventing malware has become easier over this year alone, browsers do a lot and simple A/Vs like MS' built in one or ClamAV for linux can catch most of the dangerous ones. So I'm not worried about malware. I consider local attackers a more exotic attack vector and they are rare from my experience so I'm willing to take this risk in favor of making my life easier.
    • kuschku 9y ago
      > there are plenty of services without proper 2FA (looking at you paypal, amazon and my email provider) PayPal and Amazon both support TOTP, including for all support contacts, but it’s hidden. Personally, I’ve enabled these.
      • zaarn 9y ago
        Paypal only supports SMS 2FA for me, I've checked last week again. Might be different depending on nationality. SMS 2FA is not acceptable and not secure. I also don't recall Amazon (Atleast shopping side) having 2FA either but it's been a month since I checked.
        • conorgil145 9y ago
          FYI, Amazon (retail) does support TOTP. Here is a direct link to the 2FA settings so you don't have to crawl through the account settings page looking for it: https://www.amazon.com/a/settings/approval https://www.amazon.com/a/settings/approval.
          • zaarn 9y ago