Editorial by Security Consultant, Jakub Kaluzny
As a follow-up on my last article, NIST declares the age of SMS-based 2-factor authentication over, I would like to clarify my thoughts on so-called next generation 2-FA solutions and define security mechanisms which any 2-FA solution should provide.
Assumed that the main device (computer) has already been compromised, our last resort is the 2-FA device. Which security mechanisms should it provide for the users so that they can feel secure?
Disclaimer: This guide is focused on second factor authentication AND authorisation. This is because solutions which offer a second factor for authentication only cannot be used in high-risk enterprise environments, such as financial system (online banking). When a transaction is mentioned, I mean any action in the application - financial transaction, changing e-mail address or changing 2-FA device.
The user should be aware that he is authorising a transaction
All 2-FA devices which only detect user presence and do not require confirmation do not meet this criteria. The user has to perform some action (such as entering PIN, clicking, sliding, saying something) to confirm the authorisation.
Authorised transaction details should be visible to the user
All 2-FA devices which do not have a programmable display (such as RSA tokens) or do not present transaction details (many OTP solutions, including Authy, Google Authenticator) do not meet this criteria. There has already been malware, which exploited or was close to exploit similar weaknesses (Banatrix, VBKlip, VBKlip 2.0) Devices should receive data (by GSM, keyboard, microphone or camera) and present the details such as "signing in", "sending $5000 to X" or "changing e-mail address".
If the device is stolen or compromised, the attacker should not be able to authorise transactions
The 2-FA device needs to be protected by a PIN, password or biometrics and offer a proper security at rest. If an attacker is able to record audio and video, he should not be able to repeat the authentication process. Standard PIN/password entry using keyboard may be not enough, as they don't protect from shoulder surfing (see peeking-proof lockscreen).
Transmission channel should be encrypted
In current mobile network environment, SMS messages are not bullet-proof, that's a fact. The attack vector may require physical encounter (IMSI catcher and SS7), nation-state agency privileges (access to telecommunications companies) or none of the above if voip is used (story from Coinbase). Thus, we opt for 3G data and a proper SSL channel (SSL pinning).
Security vs. usability and cost
We also want to guarantee some features which satisfy the application owner.
Non-repudiation - the fact that the transaction was authorised should imply that the user wanted it
If the 2-FA provider is a third-party, it should not be able to authorise transactions on users behalf, which protects both parties in case of a conflict. Thus, we require a cryptographic element which is not known to the 2-FA provider.
Usability - the 2-FA mechanism should be easy to implement
External tokens and card readers are a no-go. The only electronic device that (almost) everyone carries everywhere is a mobile phone. This, of course, may change in future: Estonia ID maybe?
Cost effectiveness
Banks are paying millions for sending SMS messages. Data needs to be transferred either directly from the computer (QR code, voice message, Bluetooth) or using cheap 3G data.
Putting the criteria all together, we can come into conclusions that a perfect 2-FA mechanism should be:
-
a mobile application requiring authentication (password/biometrics) which could not be repeated by an attacker able to record audio and video of the user
-
providing a proper security at rest, so that a stolen device does not allow an easy key recovery (CVE-2015-6647, CVE-2015-6639, CVE-2016-2060)
-
displaying transaction data (using any output on the mobile - display or speaker) to protect from malware similar to Banatrix, VBKlip, VBKlip 2.0.
-
requiring a confirmation (using any input on the mobile, such as touchscreen, microphone or biometrics); is re-writing token/SMS enough? No, Zitmo.
Implementation defects
Apart from the architecture flaws and high-level security requirements for a 2-FA mobile app, 2-FA solutions often have implementation defects which can turn into serious security vulnerabilities.
-
pairing mechanisms flaws, e.g. possibility to extract shared secrets of other users (server-side)
-
general 2-FA implementation problems: possibility to change 2-FA device without the old one, 2-FA bypass, brute-force, weak randomness of tokens (here is a good cheatsheet from OWASP)
-
changing e-mail address without authorisation and reissuing 2-FA device
-
weak cryptography at rest, which allows to decrypt the shared secret
And of course there is a separate chapter for abusing biometrics authentication:
-
general biometrics problem: equal-error-rate (EER) is too high yet to guarantee a proper security level without affecting the usability
-
voice biometrics abuse: replay attack with noise reduction or characteristic change (pitch, speed, pause length), background noise reduction with a second microphone
-
face biometrics abuse: presenting a photo or 3d model instead of a real person
-
fingerprint biometrics abuse: 3d models or molds instead of a real finger
Conclusion
We are sentenced to use 2-FA mobile apps in future because they can have features which are technically not possible to achieve using external card readers or SMS messages. The problem is that there are much more security issues and possible failures with implementation of mobile apps than with currently used 2-FA solutions. From my experience, mobile apps 2-FA are not mature yet in case of security. A proper testing is also not easy, especially with innovative biometric solutions which protect their patents and use nondeterministic algorithms.
