Two-factor Authentication Is Not Dead

I’ve had just about enough of the fear mongering and lazy ‘reporting’ that’s been in the press recently around how two-factor authentication is broken.

I’m not sure about you, but the way the doomsday preachers in mass media have torn apart two-factor authentication lately really has me wondering about the state of journalism anymore. I mean seriously – what in heaven’s name did two-factor do to receive such abuse lately?   

Over the past few months, there have been a rash of ‘Two-factor is broken’ articles in mainstream and industry press that needs to be addressed. In many of the numerous articles I’ve read, they all point to the same specific implementation of two-factor that is ‘broken’ – SMS-based token delivery. While we have all had concerns about this for a while, the stark reality is that the probability (you remember probability – it’s that thing we’re supposed to include in our decision making process?) of your average consumer being targeted by an SMS attack while simultaneously accessing their online bank accounts is still immeasurably small.

The other ‘flaw’ that’s been reported, thanks in part to a new startup venture, introduces the weakness of a phish into the two-factor lifecycle. Anyone who has spend even the smallest amount of time in the security world knows that there are very few things that can prevent a well crafted phish from being successful. However, the automation that we are seeing which rapidly gathers a users credentials and two-factor code an uses them against the target website is pretty impressive. To be honest, I think this is a far more probable issue than the SMS attack, but we’ll get into that a bit later.

While both of these examples are legitimate attacks, there is also the delineation between consumer and enterprise multi-factor authentication approaches that seems to have been completely ignored by these reporters.

But before we get into the seemingly single-focused desire to send two-factor to the Great InfoSec Landfill, let’s look at some key points about our much maligned super hero.

Point #1 – Two-Factor Authentication is the most basic implementation of a true multi-factor authentication solution. In fact, the SMS implementation of two-factor doesn’t technically satisfy any of the ‘something you have, you know, or you are’ criteria of a true multi-factor model. A fundamental tenet of a valid multi-factor implementation is that you already have the capability of obtaining all the factors you need to authenticate without interacting with anyone else. In the SMS two-factor world, you need to rely on third-parties to deliver one of your authentication tokens. Since those third-parties are vulnerable to a man-in-the-middle attack, the SMS model breaks the secure multi-factor design protocol. Modern, albeit flawed, thinking has us believing that since you ‘have’ your mobile device, it satisfies the first tenant of the multi-factor rule set. It does not.

In fact, the SMS implementation of two-factor doesn’t technically satisfy any of the ‘something you have, you know, or you are’ criteria of a true multi-factor model.

Point #2 – There is a huge difference between consumer facing two-factor and enterprise two-factor, a point seemingly overlooked by every piece I’ve read recently. Two-factor, and more broadly, multi-factor, remains the single best approach for protecting consumer and corporate assets in the enterprise when implemented correctly.

Point #3 – As in any solution implementation, the devil is in the details. Taking shortcuts to encourage adoption will invariably lead to weaknesses and vulnerabilities. Implementing a two-factor authentication mechanism is no different. By choosing to use a method like SMS over a biometric, hardware/NFC, or software-based token (I.e. Google Authenticator, Duo, Microsoft Authenticator, etc), you have introduced a weakness into your supposedly secure protocol.  

When evaluating the supposed death of two-factor, how do these three points play into the hysterical death-toll underway? Let’s look at some cited examples.

Consumer Financial Applications

For the most part, even a poorly implemented SMS practice is better than relying on nothing other than user ID and password. Users will reuse id’s and passwords across multiple accounts; there is simply no denying that. We are seeing a rampant uptick in bot-driven credential stuffing attacks that inherently proves what we’ve always known; that user ID and password re-use is the norm, not the exception. As I’ve previously written about, not only do normal users reuse IDs and passwords, but so do most security and IT people. You need to come to term with the fact that you will never train users out of this practice.

Since the vast majority of the 270 million⁽¹⁾ US mobile phone users are not being targeted and monitored on the mobile networks, at least for SMS tokens, the probability (there’s that word again) of a mass depletion of consumer bank accounts is still highly unlikely. So while SMS two-factor isn’t the best idea around, it’s far from the worst either.

That being said, we need to stop expecting our users to keep track of dozens of different user ID and password combinations. The industry should get ahead of the game and begin to let users start moving towards a software-based token like the free Authenticator from either Google or Microsoft (or better yet, give them a choice). In fact, if done correctly, companies could ‘eliminate’ the need for passwords with a combination of token/certificate-based device authorization and multi-factor authentication. Imagine the impact a company would have by developing a true one-time password mechanism that people were eager to adopt!  

Enterprise Applications

In most cases, enterprise applications do not rely on the SMS implementation of two-factor due to the cost of integration as well as the inherent lack of security around it (ironic – huh?). Truth is, enterprises have had the foundations of multi-factor in place for quite a long time. For years, the RSA SecurID fob was as iconic as a ‘67 Camaro – anyone who was cool had one. The challenge with SecurID was infrastructure requirements and associated costs – tokens were around $50 each and only lasted 3-5 years. These challenges, along with the logistics of getting physical token into customers hands made mass deployment a challenge, hence the SMS direction. As SecurID was relegated to the most sensitive of infrastructures, companies like Authy, Duo and Digipass made cloud multi-factor a reality.

Today’s modern enterprise infrastructure is faced with a myriad of challenges – from user mobility, to shadow IT, to the continual barrage of attacks from across the globe. We must accept that the hardened perimeter is long gone and the need to secure information must be based on identity rather than location. This is where the true value of a ubiquitous multi-factor solution is ever more apparent. Companies are dumping on-premise mail services for Office 365 or the Google Suite, giving employes anytime-anywhere access. They are building mobile apps to monitor internal dashboards and reporting systems. They leverage cloud providers for HR, payroll, and benefits. The march to ‘Everything as a Service’ has never had a louder drumbeat and it shows no signs of slowing down. Integrating these types of services with a well designed multi-factor solution is still the best way to protect any internet-facing service – regardless of what some headline-seeking journalist may tell you.

The Phish Problem

In a perfect world, multi-factor would not only solve most of our authentication problems, but it would do so in a way that users readily accepted. However, with the advent of some rather savvy commercial and underground solutions, multi-factor can no longer be blindly trusted ‘just because it’s multi-factor’. Today, understanding the way applications authenticate users, both cloud and on-prem, is critical to ensuring a higher level of trust with your multi-factor deployment.

Over the past year or two, we have seen phishing attacks which, when crafted appropriately, would fool even the most diligent user and subvert the best infrastructure. These emails are able to not only capture usernames and passwords, but your two-factor token code and use it to authenticate to the desired service almost instantly. The challenge faced by the attackers is knowing which services you use and their ability to customize the phish to match the service. Popular services like Office 365, G-Suite, and many others, give themselves away pretty easily, so presuming the attackers wont figure out that you use them is simply naive.

While these types of attacks are extremely difficult to protect against as a user of a service, an enterprise can implement techniques such as pre-registering devices, IP monitoring and adaptive authentication to mitigate the risk to a reasonable level for their customers. One thing companies cannot do is turn a blind eye to the risk and presume the logins are actually coming from the actual customer.   

Final Thoughts

The death toll for two-factor is not just overblown, but perhaps more troubling is that it is irresponsible and reckless. How many consumers are now choosing not to implement two-factor because of a story they heard on the evening news or read in some trade publication? The utter ridiculousness of some of the asertations in these articles is akin to screaming fire in a movie theater – and in my ever so humble opinion, these ‘journalists’ should be held similarly accountable.

Are there issues with the way some have taken to implement multi-factor authentication? Sure. Is better technology readily available for developing a stronger and safer solution? Absolutely. Will we see anyone step up and lead the industry to fixing the problem that itself started? Probably not.

To quote one of the greatest comedy troupes of all time, two-factor authentication is “Not dead yet”, but some of the questionable practices and implementations being used should be.

(1) https://www.statista.com/statistics/222306/forecast-of-smartphone-users-in-the-us/

For more on Identity and Access Management, view these articles.