Firstly, I really appreciate the thoughtfulness and thoroughness of the reply, you've clearly invested significant thought into these issues, which in and of it

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. [0]https://pages.nist.gov/800-63-3/sp800-63b.html#-511-memorized-secrets https://pages.nist.gov/800-63-3/sp800-63b.html#-511-memorize... [1]https://pages.nist.gov/800-63-3/sp800-63b.html#appA https://pages.nist.gov/800-63-3/sp800-63b.html#appA