Child pages
  • The Quest to Replace Passwords II
Skip to end of metadata
Go to start of metadata

Contents:

Part II: Duo Security Two-Factor Authentication

s/Password/Password \+ Duo 2FA/g
s/Federated Password/Federated Password \+ Duo 2FA/g

Methodology

In Part II, we apply the general framework developed in [1] to a sampling of Duo Security two-factor authentication technology. [3] In particular, two Duo Security mobile-based authentication schemes are evaluated: Duo Mobile and Duo Push. Since Duo two-factor authentication builds on traditional passwords (instead of replacing them like the majority of the schemes evaluated in [1]), the results are not obvious and therefore worthy of analysis.

Here we deviate from the framework in [1] in one very important way. Recall that every scheme in [1] is compared against the Password scheme, since after all, we are on "a quest to replace passwords." Here in Part II, however, we begin by comparing Duo Mobile and Duo Push against the ordinary Password scheme, and then complete the analysis by comparing the same Duo schemes against the Federated Password scheme introduced in Part I. Thus the overall goal here is to evaluate four new authentication schemes:

  1. Password + Duo Mobile
  2. Password + Duo Push
  3. Federated Password + Duo Mobile
  4. Federated Password + Duo Push

The first two schemes above assume Duo is installed at the service provider, whereas the latter two schemes evaluate Duo at the identity provider. (The case of distributed two-factor authentication, where the federated password is managed by a trusted identity provider and the second Duo factor is verified directly at the service provider, is not studied here.) For installation at the service provider, Duo provides an SDK called Duo Web. Duo also supplies a Shibboleth Two-Factor Authentication Login Handler that may be used by a Shibboleth-based identity provider.

As in Part I, the 25 benefits listed in the tables below are those identified in section II of [1]. Each Duo Security two-factor authentication scheme is compared and contrasted according to these benefits.

Executive Summary

Not surprisingly, Duo two-factor authentication is considerably more secure than password alone. What is surprising, however, is that the security benefits are uniform across all two-factor authentication schemes studied. That is, from a strict security point of view, it doesn’t matter which Duo technology is used or the type of password used.

In terms of usability, the results are more variable. Clearly federated password alone is the most usable option. More interesting is that any Duo scheme deployed on top of ordinary passwords lacks usability with respect to a handful of key benefits, whereas Duo deployed on top of federated passwords does much better. Indeed, from a pure usability perspective, a federated password followed by Duo Push is very competitive with a federated password alone.

As observed in section VI of [1], “every scheme does worse than passwords” in terms of deployability, and unfortunately the schemes studied here are no exception. Duo is only Quasi-Negligible-Cost-per-User (which is perhaps overly generous) and of course Duo lacks the Non-Proprietary benefit (although all of the Duo client code is open source). We will have more to say about deployability in the discussion section.

Duo Security Two-Factor Authentication

We now rate four Duo Security two-factor authentication schemes using the framework in [1]. In what follows we refer to these schemes using the indicated abbreviations:

  1. Password + Duo Mobile (P+DM)
  2. Password + Duo Push (P+DP)
  3. Federated Password + Duo Mobile (FP+DM)
  4. Federated Password + Duo Push (FP+DP)

Note that all Duo two-factor authentication schemes layer on top of the Password or Federated Password scheme. Thus the reader is encouraged to read section V-E “Combining Schemes” in [1] since it applies directly to the two-factor authentication schemes studied here.

Finally, since Duo Mobile is related to OTP over SMS (section IV-I4), at least in terms of the user operations required, the evaluations of P+DM and FP+DM borrow heavily from the authors’ conclusions regarding the OTP over SMS authentication scheme, and so the reader is encouraged to read that section as well.

 

 

U1

Memorywise-Effortless

U2

Scalable-for-Users

U3

Nothing-to-Carry

U4

Physically-Effortless

U5

Easy-to-Learn

U6

Efficient-to-Use

U7

Infrequent-Errors

U8

Easy-Recovery-from-Loss

D1

Accessible

D2

Negligible-Cost-per-User

D3

Server-Compatible

D4

Browser-Compatible

D5

Mature

D6

Non-Proprietary

S1

Resilient-to-Physical-Observation

S2

Resilient-to-Targeted-Impersonation

S3

Resilient-to-Throttled-Guessing

S4

Resilient-to-Unthrottled-Guessing

S5

Resilient-to-Internal-Observation

S6

Resilient-to-Leaks-from-Other-Verifiers

S7

Resilient-to-Phishing

S8

Resilient-to-Theft

S9

No-Trusted-Third-Party

S10

Requiring-Explicit-Consent

S11

Unlinkable

Comparison of Duo Security Two-Factor Authentication to Password and Federated Password
 = offers the benefit;  = almost offers the benefit; no circle = does not offer the benefit.
U = usability benefit; D = deployability benefit; S = security or privacy benefit.

Duo Usability Benefits

U1. Memorywise-Effortless. This benefit follows directly from the underlying password technology since Duo makes no additional memory demands upon the user. Neither P+DM nor P+DP are Memorywise-Effortless since Password alone is not Memorywise-Effortless (section III). On the other hand, both FP+DM and FP+DP are Quasi-Memorywise-Effortless because Federated Password alone is Quasi-Memorywise-Effortless (section IV-C1).

U2. Scalable-for-Users. Neither P+DM nor P+DP are Scalable-for-Users since Password alone is not Scalable-for-Users (section III). Since Federated Password is Scalable-for-Users (section IV-C1), both FP+DM and FP+DP depend on the corresponding Duo technology. We deem Duo Push to be Scalable-for-Users and therefore FP+DP is Scalable-for-Users. Duo Mobile is Scalable-for-Users since OTP over SMS is Scalable-for-Users (section IV-I4), and therefore FP+DM is Scalable-for-Users as well.

U3. Nothing-to-Carry. For the reason discussed in section II-A in [1], all of the Duo schemes are Quasi-Nothing-to-Carry since they require a mobile phone, a device typically carried all the time anyway.

U4. Physically-Effortless. Since typing a password is not Physically-Effortless (section III), neither P+DM nor P+DP are Physically-Effortless. Likewise FP+DM is not Physically-Effortless since OTP over SMS (and therefore Duo Mobile) is not Physically-Effortless. On the other hand, FP+DP is Quasi-Physically-Effortless since Federated Password is Quasi-Physically-Effortless (section IV-C1) while Duo Push adds negligible physical effort to the login process.

U5. Easy-to-Learn. Since Duo itself is easy to learn, both P+DM and P+DP are Easy-to-Learn since Password alone is Easy-to-Learn. Similarly, both FP+DM and FP+DP are Quasi-Easy-to-Learn since Federated Password is Quasi-Easy-to-Learn. (Recall that both OpenID and SAML Web Browser SSO are Quasi-Easy-to-Learn since both flows begin at the relying party and therefore require user interaction to begin the process.)

U6. Efficient-to-Use. Although any type of password is Efficient-to-Use, observe that OTP over SMS (and therefore Duo Mobile) is Quasi-Efficient-to-Use (section IV-I4), and therefore both P+DM and FP+DM are Quasi-Efficient-to-Use. On the other hand, both P+DP and FP+DP are fully Efficient-to-Use since all factors are Efficient-to-Use. In particular, Duo Push is Efficient-to-Use.

U7. Infrequent-Errors. Since both Password and OTP over SMS do not have Infrequent-Errors, P+DM does not have Infrequent-Errors. At the other extreme, FP+DP has Infrequent-Errors since both factors have Infrequent-Errors. The remaining schemes (P+DP and FP+DM) have Quasi-Infrequent-Errors since exactly one of the factors has Infrequent-Errors (while the other does not).

U8. Easy-Recovery-from-Loss. None of the Duo schemes are Easy-Recovery-from-Loss since a lost mobile phone takes time to replace, and moreover, each scheme relies on an authentication secret stored on the phone (which complicates recovery, as noted in section IV-I5). In the case of Duo Mobile, this is a shared key (since the scheme is based on OATH HOTP), while in the case of Duo Push, a private key is stored on the mobile phone. In either case, both revocation and re-enrollment are necessary.

Duo Deployability Benefits

D1. Accessible. Both P+DM and FP+DM are Quasi-Accessible because OTP over SMS (which involves user operations similar to Duo Mobile) is Quasi-Accessible as shown in section IV-I4 in [1]. On the other hand, both P+DP and FP+DP are fully Accessible since Duo Push requires a single button push, which we claim is equivalent to a text-based operation if implemented correctly.

D2. Negligible-Cost-per-User. All of the Duo schemes are Quasi-Negligible-Cost-per-User for the same reason other phone-based schemes in [1] are Quasi-Negligible-Cost-per-User, that is, it is likely that “most users will already have a phone, though perhaps not one of the right type.” (A recent survey of mobile phone usage for a sub-population of higher ed users suggests that this is so.)

D3. Server-Compatible. Neither FP+DM nor FP+DP are Server-Compatible since Federated Password is not Server-Compatible (but see the discussion section for an alternative viewpoint). If an ordinary password is used, a very modest deployment effort is required at each service. Therefore both P+DM and P+DP are Quasi-Server-Compatible.

D4. Browser-Compatible. All Duo schemes are Browser-Compatible since they require an HTML iframe and JavaScript in the browser.

D5. Mature. All Duo schemes are considered to be Quasi-Mature at this time. Although the underlying security protocols (OATH HOTP, PKCS#7) are standardized and/or mature, and much of the Duo code base is open source as well, the company itself is still young and so its future is uncertain.

D6. Non-Proprietary. None of the Duo schemes are Non-Proprietary even though the underlying security protocols (OATH HOTP, PKCS#7) are standardized and unencumbered. In particular, Duo Push is patented technology. Beyond this, it is not known what patents Duo Security holds and how they relate to the schemes under consideration. (It’s interesting to speculate whether the Duo Mobile app, for example, could be used with other server implementations of OATH HOTP.)

Duo Security and Privacy Benefits

S1. Resilient-to-Physical-Observation. All of the Duo schemes are Resilient-to-Physical-Observation since the operation on the phone is either a transcription of a one-time password (Duo Mobile) or a button push (Duo Push). So even if both the password and the phone operation were repeatedly observed, possession of the mobile phone (“something you have”) is still required for a successful login.

S2. Resilient-to-Targeted-Impersonation. All of the Duo schemes are Resilient-to-Targeted-Impersonation since personal knowledge of the user can not be used to bypass the “something you have” phone operation. (That said, we emphasize that this benefit applies to the authentication scheme in general, not necessarily to each and every user of the scheme. This point is discussed further in the discussion section.)

S3. Resilient-to-Throttled-Guessing. Even if an attacker were able to guess or otherwise obtain the user’s password, all of the Duo schemes would resist such an attack thanks to the second factor. Thus the Duo schemes are Resilient-to-Throttled-Guessing.

S4. Resilient-to-Unthrottled-Guessing. As above, all of the Duo schemes are Resilient-to-Unthrottled-Guessing thanks to a strong second factor. In particular, the asymmetric key used by Duo Push is a 2048-bit key.

S5. Resilient-to-Internal-Observation. Since the authors of [1] explicitly “grant Quasi-Resilient-to-Internal-Observation to two-factor schemes where both factors must be malware-infected for the attack to work,” all of the Duo schemes are so rated according to this framework. (As an aside, it seems that only paper tokens and hard tokens have this benefit.)

S6. Resilient-to-Leaks-from-Other-Verifiers. Scheme P+DM is Quasi-Resilient-to-Leaks-from-Other-Verifiers since two independent verifiers would have to leak their respective secret. Scheme P+DP is fully Resilient-to-Leaks-from-Other-Verifiers since the Duo Push verifier uses a public key (not a shared key). Like a Federated Password alone, FP+DM is Resilient-to-Leaks-from-Other-Verifiers since relying parties don’t have access to federated passwords. Similarly, FP+DP is Resilient-to-Leaks-from-Other-Verifiers as well, but in this case neither verifier has access to a secret.

S7. Resilient-to-Phishing. All of the Duo schemes are Resilient-to-Phishing, which is a primary benefit of Duo two-factor authentication. Recall that federated authentication schemes in particular are extremely vulnerable to phishing. Duo mitigates this vulnerability and therefore shifts the "weakest link" to elsewhere in the workflow.

S8. Resilient-to-Theft. Like Google 2-Step Verification as discussed in Part I, all of the Duo schemes are Quasi-Resilient-to-Theft assuming the phone is passcode-protected. This is because an attacker has access to the user’s e-mail on the phone and can therefore reset the password using the phone itself. This of course is why it's so important to passcode-protect a mobile phone, regardless of whether or not it is used as an authentication token.

S9. No-Trusted-Third-Party. Since a Federated Password alone does not enjoy the No-Trusted-Third-Party benefit, neither FP+DM nor FP+DP are No-Trusted-Third-Party. Even though a Password alone is No-Trusted-Third-Party, neither P+DM nor P+DP are No-Trusted-Third-Party since a compromised Duo server could leak the user’s username and/or mobile phone number. Although this “feels like” a Quasi-No-Trusted-Third-Party benefit, there is no such example in [1] so none of the Duo schemes are awarded this benefit for lack of a specific example.

S10. Requiring-Explicit-Consent. All of the Duo schemes are Requiring-Explicit-Consent but for different reasons. Both P+DM and P+DP are Requiring-Explicit-Consent since the user is required to type a password. On the other hand, both FP+DM and FP+DP are Requiring-Explicit-Consent since the user is required to select an opaque ‘identity URL’ (in the case of OpenID) or their preferred identity provider (in the case of SAML Web Browser SSO). In either case, explicit user action is required.

S11. Unlinkable. Since a Password alone is Unlinkable, both P+DM and P+DP are Unlinkable. Similarly, since a Federated Password alone is Unlinkable, both FP+DM and FP+DP are Unlinkable.

Discussion

Benefits of Duo 2FA

Perhaps the most important result of this study is that the security benefits of Duo two-factor authentication are uniform across all the schemes studied. And so a deployment can realize the same security benefits regardless of the underlying password infrastructure or the types of phones held by users. I think it’s also fair to say that a federated password followed by Duo Push is almost as usable as a federated password alone, so if your users already have federated passwords, by all means use them in conjunction with Duo.

Mobile Phone Loss

As noted in the evaluation section, none of the Duo schemes are Easy-Recovery-from-Loss while each is only Quasi-Resilient-to-Theft. Any attempt to address these weaknesses should be done deliberately and carefully. Although lost phones are a distinct and real possibility, there is some consolation in the fact that they are not a "weak link" to be easily exploited by an active attacker. Indeed, as was shown by a very recent compromise of Google 2-Step Verification [4], the more important weaknesses (i.e., the ones that are exploitable) revolve around the change password and password reset functions. These familiar workflows need to be optimized and hardened before injecting them into two-factor authentication workflows.

An initial deployment of two-factor authentication should begin with a fairly conservative password policy. In particular, e-mail-based password reset, although standard fare in many low-security web apps, may not suffice for today's high-security web apps. Indeed, in the absence of secure e-mail (which doesn't seem like a cost effective solution in any case), e-mail-based password reset remains a weak, exploitable process in general. Other, more secure methods of password reset are sought.

Since a mutually authenticated secure channel will most likely be hard to come by, yet another independent channel may provide adequate security for high-risk web apps. For example, the Duo cloud solution supports multiple phones per user, so it's not unreasonable to require an independent non-mobile phone number (in addition to a mobile phone number for two-factor authentication) for that rarely needed password reset. (A non-mobile phone number is associated with a non-mobile device, by definition.) This "other phone number" could be used in a variety of exceptional circumstances. For example, in the event of a lost or stolen phone, the non-mobile phone number gives rise to a much needed communication channel.

The bottom line is: instead of a second e-mail address, consider the possibility of a second phone number.

Server Compatibility

In the evaluation section, it is concluded that both FP+DM and FP+DP are not Server-Compatible since Federated Password is not Server-Compatible in relation to Password alone. But what if Federated Password is already deployed? In that case, Duo adds no incompatibility at the service provider whatsoever, and so in that sense both FP+DM and FP+DP are Server-Compatible. At the identity provider, at least in the case of the Shibboleth identity provider, a very modest deployment effort is required to deploy Duo on top of Federated Password, thanks to the Shibboleth Two-Factor Authentication Login Handler from Duo Security.

Extending the Benefits

A number of important deployability benefits are omitted from this framework, such as Negligible-Setup-Cost and Negligible-Support-Costs. The latter is extremely important when considering a new (or enhanced) authentication technology, especially since the Password scheme lacks this benefit.

Also, the Negligible-Cost-per-User benefit is not granular enough for our purposes. This benefit could be broken down into two separate benefits: Negligible-Fixed-Cost-per-User and Negligible-Variable-Cost-per-Login. Then OTP over SMS, for example, would have the former but not the latter. A technology like Phonefactor would likewise not be awarded the Negligible-Variable-Cost-per-Login benefit since voice calls have a significant marginal cost. On the other hand, hard tokens (such as RSA SecurID and YubiKey) would presumably have Negligible-Variable-Cost-per-Login but not Negligible-Fixed-Cost-per-User (just the opposite of OTP over SMS). These are important considerations.

The table below includes all of the new benefits discussed in this section.

 

 

D7

Negligible-Setup-Cost

D8

Negligible-Support-Costs

D9

Negligible-Fixed-Cost-per-User

D10

Negligible-Variable-Cost-per-Login

S12

No-Secrets-Stored-on-the-Server

Extending the Benefits in [1]
 = offers the benefit;  = almost offers the benefit; no circle = does not offer the benefit.
U = usability benefit; D = deployability benefit; S = security or privacy benefit.

A missing security benefit is No-Secrets-Stored-on-the-Server. The Password scheme is Quasi-No-Secrets-Stored-on-the-Server since passwords are vulnerable to offline attacks. Likewise, Federated Password is Quasi-No-Secrets-Stored-on-the-Server but for a different reason: even though the number of password files is reduced to one, that one file becomes an extremely attractive target, with value equal to the sum of the individual password files required in the absence of federation.

Using a similar argument, any scheme that depends on a shared key can not be awarded the No-Secrets-Stored-on-the-Server benefit. This includes any scheme based on OATH HOTP/TOTP, such as RSA SecurID, Google 2-Step, and Duo Mobile. On the other hand, Duo Push has the No-Secrets-Stored-on-the-Server benefit since the key on the server is a public key, not a shared key. Moreover, observe that schemes based on OATH HOTP/TOTP are Resilient-to Unthrottled-Guessing but lacking the No-Secrets-Stored-on-the-Server benefit. Clearly Resilient-to Unthrottled-Guessing does not tell the whole story.

References

[1] Joseph Bonneau, Cormac Herley, Paul C. van Oorschot, Frank Stajano. The quest to replace passwords: a framework for comparative evaluation of Web authentication schemes. Technical Report Number 817, University of Cambridge Computer Laboratory, March 2012. http://t.co/VUdl7VNb

[2] Cormac Herley, Paul C. van Oorschot. A Research Agenda Acknowledging the Persistence of Passwords. August 2011. http://research.microsoft.com/apps/pubs/?id=154077

[3] Duo Security http://www.duosecurity.com/

[4] http://blog.cloudflare.com/post-mortem-todays-attack-apparent-google-app

  • No labels