SANS ISC: Three Problems with Two Factor Authentication

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

0 - Usability

Usability remains a challenge for two-factor authentication. I recently came across a review of a healthcare-related mobile app, and a one-star review complained about how unusable the application is due to its two-factor requirement. I am sure the developer considered two-factor authentication a must due to the application storing sensitive medical data. The application used a one-time-password style second factor ("Google Authenticator"), and it can be a bit difficult to switch between apps on a mobile device during login.

This is where it matters to design an authentication mechanism that is adequate for the particular use case. I am not sure if I have a better option for a healthcare application, but here are some ideas for applications that provide access to less sensitive data:

• "Remember This Device." A user only needs to provide the second factor if they enroll a new device. This is often done using a cookie. The cookie should expire after a while, so the user will have to enter the second factor maybe once a month or once a week (again: remember to weigh off the risk). Cookies can, of course, be stolen, and you should obey best practices when setting the cookie.
• Provide different 2FA authenticator options. The "Google Authenticator" is nice in that it does offer a secure and open system that is implemented in different password safes and other applications, making it more adaptable to the user, and users tend to be familiar with it. Many bad things have been written about the use of SMS, but again: it all depends on the risk. Or even something simple as an email may provide a useable option that is significantly more secure than not having any 2FA. Maybe leave it up to the user to pick an option.
• Stick to standards. Look at how other sites implement 2FA. Do not expect your users to learn a new way of doing things just for your site.
• Don't expect the user to have specific hardware (unless you want to be VERY secure). Hardware tokens are nice but a pain to use. They should be reserved for particular high-security applications. I don't think a user will carry more than 3 of them. So if you are not one of the top three security-relevant applications a user needs to access, you should probably stick to the less secure soft tokens. Exceptions may be Webauthn capable tokens that are usable with multiple applications (which comes back to sticking to standards)

1 - Resetting the 2nd Factor

Before you implement 2FA, think about how you are going to reset the 2F. People will lose phones. They will forget tokens at work/home and still need to get access to specific applications. This is a bit like the password reset problem but often more difficult. I have not seen a good implementation yet, and if anybody has any ideas, let me know. Most sites will create a "recovery code," but that code may be lost as well (either for good or to an attacker). I once had a hardware token break that I use for a bank, and it came down to "answer these questions" before 2FA was disabled for my account and a new authenticator was sent. In some cases, it can help to allow the user to register multiple tokens.

2 - Using a Token to Reset a Password

With 2FA, there are two things to lose: Your password and your token. It is important to remember that while a token will make a weak password less dangerous, the token should not be used as an excuse to have a weak password. I recently had to reset my password for an online banking account protected with a hardware token. The password reset process asked me for my username, the current token value, and the new password. My password was reset on the spot without any additional verification. In this case, a stolen token can mean a compromised account. We always joke about users writing their passwords on the back of authentication tokens, but this simplified password reset process comes down to the same things.

4 - Other Gotchas

• don't allow the same token value to be used twice, even if it is still valid
• enforce brute force protection for token values
• be careful what decisions you leave to the user

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|