Why multi-factor authentication isn't enough to secure enterprises
A couple of decades ago, I received my first “authenticator” while working at Indiana University. As explained to me then, the device generated a secure token that only it and the server would know about. In this way, the servers I was helping to support would know that the bearer of that device (me) was legit. It was a simple form of multi-factor authentication (MFA) that is still used today with single users. That was the moment when I learned “passwords are not enough,” and the beginning of “know something, have something” (aka MFA) became ubiquitous in the authentication world. I felt confident in this sort of MFA, or two-factor authentication, solution. Over the months and years that followed, I paid for a dongle for PayPal, a YubiKey for my MtGox account and a challenge-based authenticator for my bank account. Dongles fell out of fashion over the years in favor of a TOTP (time based one time password) solution that could be generically implemented across many services. You’re probably familiar with Google Authenticator or Authy, both compatible applications with SecureLink mobile authenticator MFA solution. Used in addition to email and/or SMS-based two-factor authentication, authenticator-based MFA has a significant advantage because it can’t be stolen, or so we often think.
MFA’s aren’t as safe as they appear
It is true that if we use a TOTP authenticator, no one can steal a code being sent from a server to a user (unlike Email or SMS). It’s entirely possible, however, for “bad guys” to steal that token on the way to the server. There are limits to this attack, and those limits are generally around some sort of social engineering like phishing or spear phishing. The gist is that a “bad guy” emails you claiming to be your bank. You go to the false bank website and enter your username and password followed by your TOTP (or Email/SMS) MFA token. The bad guy now (in real-time) logs into your real bank account and locks you out (or worse yet, continues to proxy your connection so that you are none the wiser). So, are MFA solutions like email, SMS and TOTP tokens worthless? No. But it’s here where we learn that just single access control, like MFA, isn’t enough when it comes to cybersecurity and critical access management. The truth is: every authentication solution is vulnerable to some sort of attack. This is why we need to use multiple layers of security and protect every part of an access point. Because of this, we need to be aware of the “path of least security.” For example, if you force passwords to be:
- 80 characters long
- Upper/lower-case
- Contain symbols
The passwords would be, theoretically, unhackable. What if, however, you also allow the password to be reset by a technician over the phone? Increasing password requirements to 90 characters will not buy you any additional security! We need a holistic approach to network security, one that recognizes every avenue of attack and protects not just the perimeter but also the interior.
The solution is more than MFA
I always recommend multiple layers of authentication security, zero trust network access, fine-grained access controls and most importantly: training! We saw above how an MFA solution can be “hacked” with social engineering, and I’m sure you can dream up a few more ways off the top of your head. The best solution, then, is to not rely on one singular solution, like multi-factor authentication, but to create a cybersecurity mesh that mixes access policies, access controls and access monitoring to protect your assets from every angle. As mentioned above, no policy or control will fully work unless every user is educated and trained. Unfortunately, despite the advances in cybersecurity, social engineering and phishing are still successful. The best security is knowledge and understanding coupled with layers of technical security. So instead of having to enter that 90 character password, we’re focused on protecting our critical access points and assets through robust practices. This article originally appeared in InfoSecurity.