[SANS ISC] Three Problems with Two Factor Authentication, (Tue, Aug 3rd)

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Source: Read More (SANS Internet Storm Center, InfoCON: green)

You might be interested in …

[ThreatPost] Why Your Business Needs a Long-Term Remote Security Strategy

All posts, ThreatPost

Chris Hass, director of information security and research at Automox, discusses the future of work: A hybrid home/office model that will demand new security approaches. Source: Read More (Threatpost)

Read More

[ZDNet] Japanese government official says Olympic ticket data leaked

All posts, ZDNet

The announcement of a breach came one day after the FBI released a warning about cyber actors aiming to disrupt the event. Source: Read More (Latest topics for ZDNet in Security)

Read More

[TheRecord] Google open-sources Allstar, a tool to protect GitHub repos

Google has open-sourced today a project named Allstar that can be used to secure GitHub projects by constantly watching and enforcing a set of security policies with the hope of preventing basic security misconfigurations. Available as a GitHub app, Allstar can be installed on organizations and user accounts and allow it access to desired repositories. Under the […]

Read More

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.