Introduction
The two tables on this page are used to explain our selection of acceptable multi-factor authentication technology for use in assurance profiles. Table 1 describes commonly used authentication factors and summarizes their resistance to common threats. Table 2 summarizes Authentication Types or Groups of Types which meet the needs of authentication profiles.
Table 1 - Authentication Factors and Threat Resistance
| AuthN Type Number | Authentication Factor | Resistance to Threat | ||||
|---|---|---|---|---|---|---|
| Theft (Phishing, etc.) | Theft via Dynamic MITM Phishing | Guessing / Offline Cracking | MFA Device Compromise | User Workstation Compromise | ||
| 1 | Password | Low | Low | Depends | n/a | Low |
| 2 | Phone call see Voice Restrictions, note 1 | Low | Low | High | Low | High |
| 3 | Phone call (VoIP) see Additional VoIP Restrictions, note 2 | Low | Low | Medium | Low | High |
| 4 | SMS | Low | Low | High | Low | High |
| 5 | SMS (VoIP) see Additional VoIP restrictions, note 2 | Low | Low | Medium | Low | High |
| 6 | HOTP cell phone software see notes 1 and 3 | Medium | Low | High | Medium | High |
| 7 | TOTP cell phone software see notes 1 and 3 | Medium | Low | High | Medium | High |
| 8 | HOTP token | Medium | Low | High | High | High |
| 9 | TOTP token | Medium | Low | High | High | High |
| 10 | HOTP written (back up codes) | Low | Low | High | High | Low |
| 11 | DUO Push see note 3 | High | Low | High | Medium | High |
| 12 | FIDO U2F token with password | High | High | High | High | High |
| 13 | PKI device certificate with device password | High | High | High | High | Medium |
| 14 | PKI token certificate with token password | High | High | High | High | High |
Notes:
- Voice Restrictions: Institutions deploying a phone call based solution for one of their authentication factors must incorporate multi-factor authentication concepts into their security awareness training. Specifically, a prohibition on configuring voicemail greetings to respond to MFA prompts must be in-place and discussed in training. Training should also include the prohibition against using Enterprise passwords on personal devices.
- Additional VoIP Restrictions: The use of VoIP systems (or traditional PBX solutions) that use the Enterprise password for call control or call redirection may not be used. The creators of this document note that accessibility needs can often be addressed using a hardware token instead of a voice-based solution.
- Campus deployers should pay careful attention to cell phone security. Some data sources report that the majority of Android devices are not updated and are thus highly vulnerable. Some vendors have the ability to restrict MFA use to fully patched cell phones. This table assumes that cell phones used for MFA are receiving software updates.
Table 2 - Authentication Types and Combinations of Authentication Types that meet profile requirements.
The Standard MFA Profile that we are developing now focuses on simple passwords no longer being sufficient in a modern world full of phishing threats. The Stronger MFA profile column would be for some future work to support an overall higher LoA, likely coupled with corresponding Identity Proofing requirements. It's helpful to see how the two might differ in their technology requirements.
| Item | MFA Type Number(s) from Table 1 | Standard MFA Profile (anti-phish - replace passwords) | Stronger MFA Profile (could support a stronger LoA) |
|---|---|---|---|
| 1 | 1 plus any one of 2-14 | Yes | n/a - see below |
| 2 | 12 | Yes | Yes |
| 3 | 13 | Yes | No |
| 4 | 14 | Yes | Yes |
| 5 | 1 plus any one of 12-14 | Yes | Yes |
5 Comments
Eric Goodman (ucop.edu)
I'm not clear what the distinction is in the first two rows (much later errata: this column was actually referring to columns). I think of the distinction as "phishing for later use" ("static") vs "phishing for immediate use" ("dynamic"). MITM is an attack vector that could be used to support either "static" or "dynamic" scenarios (and other methods could be used for either). With those definition, I'd raise the resistance level of some of the telephony and OTP (or at least TOTP) approaches in the "static phishing" (for later use) column.
Nicole Roy
What does 'HOTP written' mean and why is its resistance to user workstation compromise low?
Eric Goodman (ucop.edu)
This was referring to "back-up login codes" a la Google's "here are ten codes to keep in your wallet".
Nicole Roy
OK, makes sense. Maybe easier to interpret if it was listed as "HOTP back-up codes" or something.
Eric Goodman (ucop.edu)
In conversations after the workgroup submitted its report, a point came up that might require clarification or re-working:
We don't explicitly allow for an IdP to separately (a) verify your device's access to a (non-password secured) locally installed private key and (b) authenticates the user via forms (username/password). It seems like this would be okay, however, we don't clearly identify it as acceptable because all of the explicitly listed PKI-challenge based solutions in Table 1 (#11-14) indicate that password protection exists at the cert/device level. (Non-password protected H/TOTP tokens are listed, but not PKI challenge based ones).
A future, updated version of this page should probably include enough information to clarify that this approach (IdP performs separate key and password challenges) is acceptable.