Security pros need to move beyond broken two-factor authentication
Well over a decade ago (and by some still today), two-factor authentication (2FA) was seen as the holy grail – the technology that would stop attackers from using stolen credentials to access accounts and make authentication secure. Sure, it was inconvenient prompting users for a second-factor of authentication every time, but it was secure, right?
A decade later, it’s clear that those now adopting 2FA are rushing towards an already broken security model. The reality is that we’re really not that much more secure as a result of deploying a basic second factor (to provide a supposed strong authentication solution). 2FA on its own will protect you some of the time but not all the time. Which is fine, if you only want some of your organization protected, or some of your data secure from attackers.
The reality is that attacker sophistication is increasing, the cost of circumventing 2FA methods are decreasing, and any organization that settles for “good enough” authentication with basic 2FA is exposed.
There are arguably dozens of second-factor methods available in the market today, some no doubt more secure than others. Some methods of authentication are simply stronger than others due to how they’re designed and implemented. Some are going to be expensive to implement and some will be more cost effective to implement.
The intention of this piece is to provide real-world examples and justifications as to why the most commonly deployed 2FA methods still used today are insufficient to protect users and organizations fully, and offer a suggestion or two if you’re in the situation of using a basic 2FA solution or getting ready to deploy 2FA.
Out of band methods relying on an OTP (one-time passcode)
This is probably the most common group of simple second-factor methods in use today. These can be relatively cheap to implement, are “ok” from a user experience perspective, and are used across a variety of workforce and consumer apps.
Out of band methods that use an OTP really describes any 2FA method where the user possesses and has to provide a one-time passcode (usually, 4 or 6 digits in length) during the login process. Examples include one-time passcodes displayed on hardware tokens; one-time passcodes received via SMS, a telephone call, email; or one-time passwords generated in a mobile application (like Microsoft Authenticator, Google Authenticator or Duo Mobile).
How were these methods subverted? How easy is it?
One of the simplest and most effective ways in which attackers can circumvent basic 2FA is via real-time phishing. With a real-time phishing attack, it is relatively easy for an attacker to coerce the user into giving up their username, password, and one-time-passcode, by asking them to log into a phishing website. The phishing website will look and feel and imitate the log-on experience of a “real” application. This is all with the intent of gaining unauthorized access to an organizations systems and data.
Recently, FireEye released a real-time phishing tool - ReelPhish which they claim to have used successfully during their red team engagements. In fact, the FireEye article calls out that IBM Security Intelligence first reported on the use of real-time phishing in 2010. The research from the report concluded that 30% of attacks against websites that are using 2FA were being bypassed.
SMS and voice call interception
Signaling System 7 (SS7) - or more accurately an inherent weakness in SS7 (the protocol that allows carrier networks to communicate), can be used by attackers as a means of intercepting SMS messages and voice calls. SS7 was designed with little security in mind, and in the absence of authentication controls as part of its design, it relies on trust between the operators’ networks. It is this trust and lack of authentication that can be exploited and ultimately provides attackers with an opportunity to access SMS directly and Voice based one-time passcodes. This has been a proven approach used by attackers in Europe to obtain access to victims bank accounts by stealing their credentials and OTP(s). Arguably, the SS7 weakness was one of the driving forces behind NIST's original proposal to deprecate SMS based one-time passcodes at a future point in time.
The concept of using mobile-based malware to obtain one-time passcodes is not new. In the Emmental attacks on Swiss and German banks back in 2014, attackers used malicious code to scrape SMS one-time passwords (OTPs) from the SMS inboxes of customers’ Android phones and access their bank accounts. At the time this was considered to be a sophisticated attack; however, there have been numerous incidents since then. More recently there was a case where the Bankosy Trojan was leveraged with call forwarding to allow attackers to obtain voice-based OTP.
Phone Number Porting Fraud
One attack vector against basic 2FA is via phone number porting. The basis of this type of attack is via social engineering. An attacker who has access to information on an end-user can coerce a cellular company's representative into issuing the attacker with a new SIM card or moving the victim's phone number to a SIM card that the attacker already has.
According to the US Fair Trade Commission, there were 2,658 reported cases of SIM swap identity theft in January 2016 alone, and these thefts involved all four major carrier networks within the US.
Out of band push-to-accept based mechanisms
Push-to-accept based 2FA is usually the reserve for workforce users (because of the need for the user to download and enroll a third-party ‘authenticator’ application). This type of out of band push-to-accept based mechanism relies on the user to hit ‘accept’ (or ‘deny’) during the login process.
Push-to-accept authentication is prone to exploit by attackers who may bombard the user with push-to-accept requests. The attacker is seeking for the user to eventually hit 'accept' to make the requests go away. And for attackers, it's a numbers game -- bombard as many users with requests as necessary until the desired outcome is achieved.
What can organizations do to protect themselves if basic 2FA is not enough?
Here are some best practices, and questions to ask to ensure that you’re not open to attack because of antiquated and insecure 2FA solution.
1) When possible, try to avoid all basic authentication methods, including one-time-passcodes delivered by SMS, e-mail, and voice.
2) When possible, try to avoid all basic authentication methods that use push-to-accept without symbol recognition. Symbol-to-accept requires a more thoughtful action by the end-user. Instead of simply hitting ‘accept’ or ‘deny’ when prompted, the user is asked to validate their identity by selecting a symbol or letter on their mobile device that matches the one shown on their browser.
3) Evaluate adaptive access control capabilities to better secure the login process. Such methods of risk analysis should include:
- The ability to detect and block authentication requests from non-standard geographic locations.
- The ability to analyze and detect improbable authentication requests that may violate geo-velocity.
- The ability to detect the device the user is attempting to log-in from and verify that it’s a trusted device for that user.
- The ability to detect whether the user’s phone number has been subjected to ‘SIM swap’ fraud/account take over and being subjected to phone number fraud.
- The ability to detect whether the login is originating from an anonymity network and could be an attacker masking their location and their IP address.
- The ability to detect whether the login is originating from a known malicious server and could be an attacker associated with using anomalous Internet infrastructure.
Even if you use an insecure method, adaptive access control techniques layered with 2FA can provide better levels of protection than basic 2FA alone.
4) Consider adopting advanced support for FIDO based hardware tokens, like Yubikey.
5) Consider anti-phishing training and best practices for your end-users.
6) Ensure that any end-user facing self-service functionality (such as password reset or account unlock) are protected using adaptive access controls.
7) Ensure any one-time passcodes are single use only.