0 - UsabilityUsability 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:
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
--- |
Johannes 4479 Posts ISC Handler Aug 3rd 2021 |
Thread locked Subscribe |
Aug 3rd 2021 9 months ago |
That "reset password by using the 2FA token" is something that makes me particularly antsy about using SMS as 2FA. In some circumstances it could be worse to set up such SMS 2FA than to not have it at all.
|
Athanasius 9 Posts |
Quote |
Aug 3rd 2021 9 months ago |
IMO basically 2FA is not bad, but overrated.
Overrated authentication methods are bad because they make it harder to point out that "it wasn't me"; you may simply not be believed. Tools like Modlishka, Muraena, Evilgenx2 or CredSniper may be used to fool people into entering both the first and second factor on a fake website. SMS authentication is fundamentally broken in multiple ways (my "Secure SMS 2FA Proposal" in https://security.nl/posting/638977 fixes most of them, but not attacks using tools like Modlishka etc). Hardware keys are hard (if not impossible) to backup and tend to get lost (and may fall into the wrong hands). Time traveler attacks have been described for hardware tokens (i.e. https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2021-007.txt) but they also apply to TOTP-based Authenticator-apps. For example, everyone with physical access to an unlocked Android smartphone can also change the Android system date and time, and can also open Google Authenticator. Shared secrets used by, for example, TOTP may be stolen (i.e. illegally copied) from both web servers and client devices. Hence the net value of 2FA may be limited or even negative for people who use unique, long and randomly generated passwords. |
Erik van Straten 129 Posts |
Quote |
Aug 4th 2021 9 months ago |
Sign Up for Free or Log In to start participating in the conversation!