Due to you-know-what (if I have to type "corona" or "COVID" again, I'll scream), enterprises have been forced to send a massive number of employees into makeshift home offices within just a few days. That means that there was no time for the security niceties, such as properly processing RFPs for apps that were thoroughly vetted. Given the emergency, employees and IT teams worked with what they could, figuring that they would improve security on the fly as soon as circumstances permitted.
That brings us to MFA. Multifactor authentication is supposed to be just that, but it's typically deployed in the least secure manner — sending straight numeric texts to a mobile device, a tactic that is well-known to be susceptible to man-in-the-middle attacks. So, are there better ways to deploy MFA, something that can be easily executed under today's far-less-than-ideal conditions? Let's dig in.
First, though, it's worth noting that numeric texts can be undermined by quite a few things other than man-in-the-middle attacks.
"There is documented fact that SMS as a 2FA delivery channel has been consciously targeted and successfully compromised by [cyberthieves] exactly because they know it is used for 2FA delivery and by highest-target-value apps/services such as banking and PayPal," said John Herrema, senior vice president of product management at BlackBerry, which today works on security software and systems. "Successful compromises include a combination of technical compromises based on interception and socially engineered compromises, such as bribing someone to port a specific target’s mobile number so a malicious [cyberthief] receives codes. Or using a phishing attack to trick a user into entering credentials and [one-time passwords] into a fake site, which is then used to access the actual site. It is true that any form of 2FA is better than nothing, so the question is not whether some form of 2FA is better than nothing, but rather whether there is a better state-of-the-art option available, particularly for highest-target-value use cases. How you secure access to a bank account doesn’t have to be and probably shouldn’t be the same as how you secure access to a YouTube account."
It's interesting that Herrema mentioned PayPal, because PayPal quietly deploys two very different MFA approaches, although they look almost identical to the end user. I discovered this last month when looking into some European security researchers' published report that PayPal MFA was susceptible to man-in-the-middle attacks. The researchers shared their exact methodology (complete with screen captures), but a pen tester we worked with couldn't successfully replicate the attack. After multiple screen-sharing real-time discussions, it became clear that the attack only worked if the MFA option was turned off.
Huh? Yep, it was then that we realized that PayPal had a rather robust MFA text deployment for any user who activated the MFA option — which, for what it's worth, really should be everybody. But for users who declined MFA, PayPal gave them one anyway, but it was a lower-security offering. Kudos to PayPal for trying to protect all of its users, including the stupid ones who decline MFA.
Still, even PayPal's full-fledged MFA appears to be just a straight text message. There are far better ways.
Beyond the insecurity of SMS MFA, Duncan Greatwood, the CEO of security vendor Xage Security, worries about the more straightforward SIM-jacking. He encourages enterprises to have employees receive their MFA alerts through a mobile app with end-to-end encryption like Signal, Apple’s iMessage or Facebook’s WhatsApp. He also suggests that enterprises encourage employees to sign up with services that reduce the risk of SIM-jacking, such as AT&T's Extra-Security or Verizon's Administrative Lock.
"If the app service provider can integrate with it, end-to-end encrypted messaging is much better protected than SMS for distributing the verification code," Greatwood said. "But even then, SMS remains vulnerable to corrupt staff at a telco assisting in a SIM jacking. Bribes for such assistance run as low as $200."
Greatwood's caveat — "if the app service provider can integrate with it" — is crucial, though. There are two categories of risk at issue here: Risk 1, malware sneaking into a corporate device (or a consumer device being temporarily used as a corporate device, with virus-related worries about how temporary temporary will be) from any site or app download that the employee/end user interacts with; and Risk 2, unauthorized direct access to enterprise assets.
This is pushing the security demands of a mobile strategy, specifically because it is redirecting so much internal network access to remote access. IT and Security have almost no control over Risk 1, which is why the only option there is to beg for employees to use better security on their own, when accessing bank accounts, retail sites or streaming video. Some can try making it an employment requirement for any device that also houses or accesses enterprise data, but there is a serious limit as to how much of that is enforceable.
Risk 2, on the other hand, is far more under the control of IT and Security. Greatwood recommends an approach that can, sometimes, sit atop a VPN system. If that can be delivered, it would be a huge help in addressing Risk 2.
"The next step up is on-phone apps that provide the second factor automatically, usually based on a TOTP (time-based one-time password) system with a seed derived from the user’s identity. This approach will be familiar to anyone who uses Google’s MFA system with apps such as Gmail or Google Drive. It is available with third-party apps such as Authy or OTP Auth and is sometimes built into VPN clients. Another way of thinking about TOTP MFA is that it uses access to the phone — presuming the TOTP app is running on the phone — as the second factor to prove identity alongside a password," Greatwood said. "Hardware keys, such as YubiKey, can provide a hardware-backed second factor, similar to but stronger than a TOTP app on a phone."
Hardware keys are more secure, but if they are stolen, they can make the security authentication problem far worse. A lot of people — and I'm guilty of this — leave their hardware keys on a literal keychain, along with their car and house keys. In my case, this makes it a pain to get it when needed, since I won't typically have it on me while working. But of far greater concern is when I am working outside of my office. Back in the pre-you-know-what days, I might be at a coffee shop, typing away on my laptop, with my keychain in my coat pocket. If an observant thief watched closely enough, the thief could wait for me to leave my table briefly to grab another coffee and steal both my keys and the laptop. In that case, I am in a worse position than I would have been otherwise. That said, it's still a good idea.
Greatwood also brought up corporate ID badges as another potential MFA factor, if the badge system is integrated with the IT sign-on system. "One issue here though is that the token on a badge may be relatively insecure — lacking in entropy and/or complexity — depending on when the badging system was designed. Badges are relatively easy to lose or steal, and integration between badges and digital IT sign-on may be lacking. Also, badge readers may not be available where users need to sign in. Badges tend to be used only for specialized site-access-related applications," he said.
Although it will take more time and cooperation to deploy, Greatwood foresees leveraging the biometrics authentication that's already integrated with many current mobile devices. Facial recognition is most common today, but I'm seeing a return to fingerprint options to sidestep the many facial-recognition hiccups. Many enterprises already use mobile biometrics for authentication customers, so it's not a big leap to using it for employee, contractor and partner authentication.