SSO/MFA, IAM Technologies, Endpoint/Device Security

Why you should deploy modern multi-factor authentication

Share

No right-thinking organization should rely on passwords alone for user authentication. We all know that passwords can be reused, cracked or phished.

It’s less obvious, but just as true, that many forms of multi-factor authentication (MFA) can also be phished or abused, including texted codes or code-generating smartphone apps.

To maintain a strong security posture, organizations need to move toward modern, phishing-resistant forms of MFA such as hardware tokens, smartphone-based passkeys and biometrics.

Organizations will also need to implement dynamic, risk-based MFA protocols that take context into account when presenting users with an authentication challenge.

"We've actually seen specific types of MFA in the wild, like just a simple push notification, be exploited, " says Brandon McCaffrey, Solutions & Product Strategy, Workforce at CyberArk.  "This idea of unphishable MFA, or phishing-resistant multifactor authentication, has become really important to the largest organizations as well."

Weakening over time

Any form of MFA is better than no MFA at all. But in practice, the way that MFA is used by many organizations leaves a lot to be desired.

"The concept of MFA was a really solid one," says Julian Mihai, CISO at Penn Medicine. "The way it's being implemented these days, it's becoming less and less strong."

For example, temporary one-time passcodes (TOTPs) texted to users via SMS  can not only be phished, but can also be intercepted by "SIM swappers" who steal the mobile phone numbers of high-value cryptocurrency holders by social-engineering carrier technical representatives.

Simple "yes"/"no" push notifications are a bit more secure, but they can be undermined by "MFA bombers" who harass users with endless confirmation requests until the users tap "yes" just to make them stop.

Authenticator apps and key fobs that generate random codes every minute are also safer than texted codes, but their users are just as susceptible to being tricked into entering the codes on phishing websites.

In each of these scenarios, if the attacker has obtained the target's password through a data breach or another phishing attack, it's game over.

"With things like Google Authenticator, you just know too much," says Mark Dorsi, CISO at Netlify. "It's just a rotating password."

"I've seen attacks out there in the world where, because you know those two pieces of information, they're able to man-in-the-middle attack you and drop out that information and then plug it into the correct site," Dorsi adds. "They only need 60 seconds."

Even the largest organizations fall victim to social-engineering attacks that reveal MFA secrets. In the 2023 MGM Resorts attack, a help-desk operator was tricked by a convincing caller into resetting the MFA on a privileged-user account.

That let the attackers take over the company's IAM platform and Microsoft Azure cloud assets, then lock up its VM servers with ransomware. MGM Resorts had to shut down its systems nationwide, eating costs of about $100 million in repairs and lost business.

"If somebody is able to trigger help-desk analysts to find other ways to register their own phone or their own application, then all of a sudden, that second factor is not really something that you have," says Mihai.

One way to beat MFA bombing is to go beyond simple "yes-or-no" push notifications and instead ask users to verify a number that the notification presents. Microsoft has adopted this protocol with its push notifications and authenticator mobile app.

"There's companies out there that have put controls in place to be able to prevent MFA bombing, and they've done number matching and some other things," says Ed Moore, AVP of IT Security - Identity and Access Management, Carnival Corporation. "I see that as a definite improvement over what they have had. But if you're in a financial [organization], if you're in a government organization, that's not going to be enough, either."

No phishing allowed

Hardware-based second factors, such as standalone keys like Yubikeys, or smartphone-based hardware tokens based on biometric authentication, drag MFA into the modern age. These protocols cannot be phished or socially engineered, as only the person possessing the actual USB key or smartphone can log in.

"I'm a very big fan of physical access tokens," says Dorsi. "The Touch IDs of the world, Yubikeys of the world, Windows Hello, Face ID, all those sorts of things. It's the thing that you have versus that thing that you know, and that's an important distinction when it comes to MFA."

Yubikeys and other USB- or NFC-based hardware tokens will cost your organization $20 to $75 per unit, depending on their capabilities. Dorsi calls that "a small price to pay in an organization in order to get a hardware-protected environment."

A cheaper route takes advantage of the fact that every smartphone sold in the past few years has a biometric face or fingerprint reader. That makes smartphones ideal for passkeys, which create public-private cryptographic key pairs between web domains and devices.

If you put a Google passkey on your Windows laptop, you'll automatically sign into Google when you use your Windows Hello fingerprint, face or device-bound PIN to log into your PC. Create a Facebook passkey on your iPhone, and it will replace your Facebook password when you open the Facebook app.

Like hardware tokens, passkeys can't be phished or spoofed because only that device can use its own passkey — at least in theory.

"There's no right or wrong here for this type of scenario," says Maor Franco, Product Marketing at CyberArk. "For example, if you're on your mobile device, the optimal way of authenticating is through passkeys."

The catch is that in many instances, new passkeys must be created for each device you use, even if you already have an account with that service.

Apple lets single users "share" passkeys among Apple devices, Google permits the same with Android devices, and Microsoft now lets you do so if you have a Microsoft account.  From a security perspective, it might still be wiser to take the trouble to create new passkeys for each phone or laptop.

Ditching the password for good

As passkeys, hardware tokens and biometric identifiers become more widely used as second factors, it will be easier for organizations to switch to completely passwordless authentication schemes. Combining a hardware factor and a biometric factor is still MFA, after all, even without a password.

"About a year ago, we switched over to being completely passwordless. At this point in time, we're all physical-token-based," says Mark Dorsi. "We've drastically reduced the ability for someone to phish us."

If there’s no password, there’s no digital form of authentication to steal, depriving potential attackers of a powerful weapon. From a user or organizational perspective, however, going passwordless is a big paradigm shift that may not always be embraced.

“There are companies that just simply do not like passwordless,” says Moore. “They're worried about their biometrics getting stolen, you can't change your fingerprint, and other things like that."

Dorsi says he’s seen a lot of resistance to passwordless schemes from users as well — until they start using the new system.

"In the beginning, there's, 'Oh, change!' and fear, uncertainty and doubt,” he says. “But all of a sudden, they find out, 'Oh, there's no more password!' They touch this button every single time and they're into their device. That makes folks very happy as you go forward."

Factoring in the user-based risk

If you’re not yet ready to go the passwordless route, then your organization can still strengthen its MFA security by implementing dynamic, risk-based authentication (RBA) challenges, which have become a vital part of every modern IAM solution.

"Risk-based authentication applies varying levels of stringency to authentication processes based on multiple data points to determine the likelihood of a security risk," explains Ben Saine, Principal Consultant at ISG. "If an access request is made from an unfamiliar location or device, the system might require additional verification prior to granting access."

In "traditional" MFA, a second authentication factor is demanded only when a user logs into a network from a device that the user hasn’t been observed using before, from a device that hasn't been used for a long period of time, or from an unfamiliar Internet Protocol address.

The possibility of IP address and device spoofing means that some attackers might get around these safeguards. To counter that, risk-based authentication adds additional criteria that, in context, might merit a second-factor challenge.

For example, is the user logging on in the middle of the night? Is the user meant to be on vacation? Are they logging on from someplace thousands of miles from where they were one hour earlier — or thousands of miles from another device they're currently using? If so, the system will ask for more authentication.

"Contextual awareness capabilities are crucial, enabling the system to consider factors like user location, device security status, and typical behavior patterns to dynamically assess risks," says Ari Harrison, Director of IT at BAMKO.

In the future, artificial intelligence may make risk-based authentication even more accurate. It could consider factors such as an individual's typing style, perhaps to the point where authentication can happen pre-emptively, before a user even tries to log in.

"AI and machine learning can come through and say, 'Yes, this individual is who they say they are… The way they hold their fingers on the keyboard is in a very particular manner with a very particular weight, and they type in a very particular cadence," says Dorsi. "Your behavior before you go to access a thing, as processed by machine learning and artificial intelligence, will grant you access."

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.