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?
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.
I agree that U2F is generally a more secure 2FA solution than soft tokens on a phone. If you use U2F (hardware), then what are you storing in your password manager (software)? Maybe, the 2FA secrets for sites that don't support U2F yet? If so, care to share which sites you use frequently that do not yet support U2F?
Also, which password manager do you use? I ask specifically because if it is a popular commercial option (1password, LastPass, Dashlane), then your attack vector on your password vault is larger than just local malware. It also includes remote attack directly on the servers of the commercial company. Sure, your vault is encrypted on their servers, but if a hacker gets their hands on your encrypted vault via malware on your system or via their remote servers its the same outcome: they have your encrypted vault and can start to work on it. Make sure that your vault password is really strong so that it cannot realistically be brute forced (I'm sure you already know that).
well 1password has wifi sync, and also sync via icloud/dropbox, so unless you use their built in service, it’s not really an issue (at least for targeted attacks)
also, they store the vaults encrypted anyway; you unlock it locally with a password, so even with a hack you still are reasonably safe.
>Maybe, the 2FA secrets for sites that don't support U2F yet?
That, yes, I put the 2FA secrets in there. They're also on my phone but I believe these are mostly outdated now since I tend to swap 2FA secrets about once a year.
>Also, which password manager do you use?
I use KeepassXC, it's a C++ implementation of Keepass which has excellent cross-platform support (Linux and Windows both work very well) and has integrated Keepass HTTP.
I sync the password database to my selfhosted Nextcloud instance (hosted on a OVH dedicated server) and use a password with about 50 characters in length (I use XKCD style passwords with about 10 words in there)
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.
Paypal supports TOTP everywhere, but it’s hidden on a page not reachable via any of their sites, in their old site, and you need to run a custom python script to even generate the token you want.
Wow, that is horrible. Given that, I would argue that, for all intents and purposes, they do not support TOTP then. An average user has zero chance of doing all of that correctly. Bummer the don't support it as a first class citizen in their security UX on their main site.
Care to share a direct link to the TOTP configuration site though?
Firstly, I really appreciate the thoughtfulness and thoroughness of the reply, you've clearly invested significant thought into these issues, which in and of itself is a good sign.
Secondly, I do agree that the threat model for 2FA lacks concise definition, I've had the same thought. It certainly does make it harder to think through how to balance the convenience-security tradeoff. I suppose the resolution to that is to acknowledge that ontologically the threat model may in fact attach elsewhere, and that the specific detail of the implementation choices within a 2FA framework (hard/soft tokens, time dependent/use dependent, etc etc) should be selected based on what threat model you are addressing. So for your implementation, I would think it speaks to the dominant use-case and its dominant threat model: an individual user's myriad personal accounts, and prevention of fraudulent access. (Unless your expected use case is within an organisation's authentication framework, in which case I'm sure you'd have policy-defined software behaviour set by administrators.) In other words, I expect your typical use case is more worried about opportunistic remote attacks (after, say, stale logins and passwords being breached, or successful phishing attack) than anything targeted, and so physical access by a skilled attacker is not considered a strong threat (though 2FA has a role in preventing opportunistic physical access as well, especially when used in financial transactions). I'm sure you've given that all a lot of thought too, so consider my thoughts only for what they're worth!
> This is obviously bad, but also obviously out of scope for 2FB.
Is it though? Let's assume that the malware functions outside the browser. Are you sure your extension cannot identify a QR code, identify that it is a valid seed for 2FA, and capture that information before the page finishes rendering, before the malware would have a chance to 'see' it? You could still offer your user the chance to display it if required. I honestly don't know enough about browser extension design to know if that's feasible, but if your app could in fact present a strong mitigation against a pre-installed malware attack then, my friend, you'd have hugely contributed to your user's security.
> 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.
This is an excellent concept, and sounds well executed. I'll have to give 2FB a try by the sound of it.
> One huge benefit of 2FB being a web extension is that it can help prevent a user falling victim to a phishing attack.
This is a good benefit that I hadn't considered.
> Finally, I am curious which specific portions of NIST 800-63B are you referring to in your comment?
The new advice on memorised secrets is laid out in 5.1.1 and subsections[0], with important discussion and rationale in Appendix 1[1]. It differs significantly from what is widely presented as 'best practice'. Though advice on memorised secrets is probably out of scope for 2FB.
Am happy to discuss in email anything you like on this, I'll flick you a quick message.
> Are you sure your extension cannot identify a QR code, identify that it is a valid seed for 2FA, and capture that information before the page finishes rendering, before the malware would have a chance to 'see' it?
I am sure that any browser extension cannot defeat malware running on the system. We have to assume that the malware is robust and sophisticated. If that is true, then it can monitor my browser and steal the secret directly from the web page as soon as the response comes in from the server. Regardless of how the secret is presented to the user (QR code, plain text, etc) and how 2FB changes the rendered page, there is no way that the malware wouldn't be able to also steal it in that same time frame if it's written correctly.
> The new advice on memorised secrets is laid out in 5.1.1 and subsections[0], with important discussion and rationale in Appendix 1[1].
Gotcha. I literally downloaded this report last week and added it to my kindle along with a boatload of other 2FA related case studies, reports, and white papers. Lots of continued research reading to do. I'll keep an eye out for the section you highlighted.
Great to hear that you might kick the tires on 2FB! It is still heavily under development, but getting closer to a dev preview release. If you haven't already, join the mailing list to get notified of releases: http://eepurl.com/c7OBwj
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...
[2] http://www.zdnet.com/article/google-prompt-you-can-now-just-...