Unprotected Session Tokens Can Undermine FIDO2 SecurityUnprotected Session Tokens Can Undermine FIDO2 Security

Many organizations that have implemented passwordless authentication via the FIDO2 standard may be undermining some of the security benefits of the approach by not properly securing the sessions that take place after authentication happens.

That oversight gives adversaries an opening to use a man-in-the-middle (MITM) attack to try and steal session cookies and perform any action that a legitimately authenticated user would be able to perform, according to a new analysis by Silverfort.

Making Passwordless Authentication a Reality

FIDO2 makes passwordless authentication a reality and is very phishing-resistant, says Dor Segal, security researcher at Silverfort. However, there are some instances where FIDO suggests it can protect against MITM when that is not always the case, he says.

"We're concerned that organizations will have a false sense of security that they are completely protected from a MITM attack if they use FIDO2," Segal says. While the authentication itself is protected, the session it enables is not. "Many developers and engineers don't understand this nuance and would falsely trust they are protected against MITM when using FIDO."

FIDO2 — or Fast Identity Online 2 — is an open authentication standard from the FIDO Alliance. It enables passwordless authentication by giving users options like biometrics, USB tokens, passkeys, and WebAuthn or the Web Authentication API to log into servers and websites. Most security experts consider it a very robust protocol for protecting against phishing and credential-theft related attacks.

In a FIDO2 setup, a user first registers with a FIDO2-supported online service and chooses an authentication mechanism, such as passkeys or a USB token. During the registration process the client device generates a public and private key pair exclusively for that application or Website.

As Microsoft explains it, "The public key is encrypted and shared with the service, but the private key remains securely on the user's device." When a user attempts to sign-in to the service — or relying party in FIDO-speak — the service presents a unique challenge to the client device, which then responds to it, signs the response with the private key, and returns it. The goal is to cryptographically protect the whole authentication process in a manner resistant to phishing attacks.

Unprotected Session Tokens

The problem, according to Silverfort, is what often happens next. "Most applications do not protect the session tokens created after authentication is successful." And often during Web authentication there is no validation of the device that requested the session. This gives an MITM attacker a way to steal session tokens, impersonate the victim, and gain access to all the applications that the user has access to via single sign-on (SSO), Segal says.

Transport Layer Security (TLS) mechanisms have made MITM attacks more difficult to accomplish, Silvefort said. Even so, attackers can use methods like DNS/DHCP spoofing, Address Resolution Protocol (ARP) poisoning, and Stateless Address Autoconfiguration (SLAAC) to secure an MITM position on a network. "While MITM attacks are harder these days because most browsers use TLS, it is still possible to perform a MITM attack," Segal says. "An adversary can spoof, downgrade traffic, or use a vulnerability to secure a MITM attack."

Once an adversary has gained MITM status on a network they would need to wait and watch for the victim to use SSO to connect to a FIDO2 protected Web application. If the subsequent session is not protected, the adversary can steal tokens, perform session hijacking, and impersonate the victim. "We tested Yubico, EntraID, and Ping and in every case, we saw that FIDO2 did a great job securing the authentication, and the SSO provider," Segal says. "However, it did not prevent an attacker from stealing the session tokens, leaving the Web application vulnerable."

A Known Issue?

Mike Kiser, director of strategy and standards at SailPoint, says the issues that Silverfort has identified are well understood and exist with or without FIDO2. "You're not 'bypassing' FIDO2 in this case," Kiser says. "It's still doing the job that [it is meant for]: preventing the theft of credentials and/or their replay against the same relying party."

Also, achieving a MITM position on a target network requires considerably more effort in a FIDO2 environment, than it would take otherwise, Kiser says. He advises that organizations continue to use the identity security measures they already have in place; safeguard trusted certificate stores; implement security best practices; and continue to trust FIDO2.

Jason Soroko, senior vice president of product at Sectigo, says the Silverfort report highlights the fact that while FIDO2 itself relies on a strong asymmetric secret, the SSO implementations built around it mostly rely on a much less secure symmetric secret, such as a session token. "The main takeaway from this report is that we need to re-examine the idea of token binding and ensure that implementations of FIDO2 are not relying on a weak foundation," he says.

Token binding is a security mechanism for strengthening the security of authentication tokens. The goal is to prevent token theft and replay by cryptographically binding an authentication token to the underlying TLS connection.

Organizations using FIDO2 to secure their SSO authentication should consider changing the default setting, and turning on token-binding when possible, Segal says. "In many cases, it is developers implementing SSO who aren't as security savvy and don't even know this option exists," he says. "So we're trying to raise awareness around the importance of not only securing the authentication, but also the session that takes place once the authentication is done."