Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up MFA Rationale #137

Open
ekr opened this issue Aug 26, 2020 · 0 comments
Open

Clean up MFA Rationale #137

ekr opened this issue Aug 26, 2020 · 0 comments

Comments

@ekr
Copy link

ekr commented Aug 26, 2020

The current MFA text reads:

Multi-factor authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction. Requiring the use of MFA for internet accessible endpoints is encouraged because by requiring not only something the user knows (a knowledge factor like a memorized password) but also something that the user has (a possession factor like a smartcard, yubikey or mobile phone) the field of threat actors that could compromise the account is reduced to actors with physical access to the user.

In cases where the possession factor is digital (a secret stored in your mobile phone) instead of physical (a smartcard or yubikey), the effect of MFA is not to reduce the field of threat actors to only those that have physical access to the user, because a secret can be remotely copied off of a compromised mobile phone. Instead, in this case, the possession factor merely makes it more difficult for the threat actor since they now need to brute force/guess your password and compromise your mobile phone. This is, however, still possible to do entirely from a remote location. In particular, storing both first on second factor on the same device (for example: mobile phone) is strongly discouraged.

There are actually two major rationales for MFA:

  • Resistance to password-based replay attack (either because of phishing or password cracking)
  • Resistance to compromise of the user's device

The first of these is obtained because the second factor is not replayable. The second of these is obtained not when the secret is physical but rather when it is not software accessible. For instance, WebAuthn using a secret stored in trusted hardware on the device (as I believe is the case with TouchID/FaceID on new Safari) resists remote compromise even though it is on the same device as the users password. However, even the first of these is quite valuable, given the relative prevalence of phishing and remote compromise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant