The future of MFA is clear – but is it here yet? – Sophos News

Over the years the industry has tied itself in knots in its attempts at augmenting (or upgrading) the password, using all sorts of confusing terminology such as two-factor authentication (2FA), two-step authentication, multifactor authentication (MFA), and the more modern confusion of universal second factor (U2F), Fast IDentity Online 2 (FIDO2), WebAuthn, and passkeys.

Up until now, most of us were happy enough to get someone to adopt any of the above. Anything more than a password is an improvement, but we have now reached the point where we need to raise the minimum bar of acceptability. In this post I’ll look at the current state of bypassing “stronger” authentication methods – and, I believe, point out the best path forward.

Not two smart

Too many of the simplest “2FA” options are not true to what two-factor authentication is really meant to be. Ideally the two factors are two of the following three types: something you know (like a password or PIN), something you have (like a USB/Bluetooth token, SmartCard or public/private keypair), or something you are (like a fingerprint or faceprint). Unfortunately, most of the early solutions boil down to something you know and . . . something else you know.

Take the RSA token, SMS text message, or TOTP (time-based one-time passwords; e.g., Google Authenticator or Authy) styles of “2FA,” where in most cases you are presented with a 6-digit code that rotates every 30 seconds. While people have criticized SMS implementations of this due to the possibility of SIM swapping, the reality is they are all weak and susceptible to interception.

Here’s the problem. Imagine you are sent a well-crafted (perhaps AI-generated?) phishing email. For the scammer to succeed in compromising you at this stage, you must believe the email is legitimate, whether you are using multifactor authentication or not. This is where challenging someone for two different things they know (their password and a secret code that is dynamically generated) ends in tears: If you really think you are logging into your bank, email, or corporate account, you will happily disclose not just your password, but the secret code as well. This type of authentication is only in a single direction; the scammer is verifying your identity, but you have not verified the identity of the entity asking for the proof.

There are in fact freely available tools to automate this deception. One of the more popular is called evilginx2. Originally based on the popular web server nginx, it is now a standalone Go application that serves as an all-in-one tool to phish knowledge-based multifactor authentication and steal session cookies to bypass authentication. This has lowered the barrier for malfeasance to new depths.

How did we get here?

If we consider the history of credential compromise, it all began with sniffing unencrypted Wi-Fi or performing other network-based attacks before things were encrypted. Back in 2010 there was an infamous tool called FireSheep that was designed to allow attackers to visit a cafe and passively steal people’s logins due to the lack of encryption on the web.

In response to these attacks, and to Edward Snowden’s leaks in 2013, we moved to encrypting nearly everything online. That change secured us against what are referred to as machine-in-the-middle (MitM) attacks. We now have nearly ubiquitous use of HTTPS across the web and even in our smartphone apps, which stops any random passersby from capturing everything you might see or do online.

Criminals then moved on to credential theft, and to a large degree most of us have moved on to some variation of multifactor authentication, but again, usually merely the cheapest and easiest variation — something we know, plus an ephemeral something-else we know. This is an ineffective speed bump, and we must move on once again.

Industry consensus has, after many a committee meeting and standards body creation, settled on a widely agreed-upon standard known as the Web Authentication API, or WebAuthn. If you want to dive deeply into the confusion over the various bits and pieces, there is a Reddit thread for that, but I won’t go too deeply into those weeds here.

A walk through WebAuthn

WebAuthn/passkeys make multifactor authentication close to phish-proof. Nothing is perfect, of course, and recent research has discovered a limited-but-interesting MitM attack vector involving specialized hardware devices and a since-patched CVE, but from here forward we are referring to it as phishing-resistant multifactor authentication.

Let’s walk through the process. I want to create an account on a popular social media site. Using my smartphone or computer with passkey support, I choose to create a new account with a passkey. The site prompts me for my desired username (usually my email address). My device sends the username to the site, and it responds back with my username, a challenge, and the site’s domain name. My device generates a unique cryptographic keypair, stores it safely alongside the site name and username, signs the challenge from the site, and attaches the associated public key for the site to now use as my identifier.

Next time I go to this site, I will no longer need or use a password, which by this definition is just a shared secret and could be stolen or replayed. Instead, as shown in Figure 1, I send the username that is matched to that site’s domain name. The site responds with a challenge. My device looks up the key for that domain name and uses it to sign the challenge, proving my identity.

Figure 1: The user-experience flow of WebAuthn authorization is smooth, with most of the action occurring among the user’s credential provider, the browser, and the site

For more information, vertx.io has a developer-centric dive into the mechanics of the process.

What could possibly go wrong?

With this combination of data points, the key can’t easily be stolen or reused, and I can’t be tricked into trying to sign into an imposter site with a lookalike domain name. (There is a small attack surface here as well: If you add a passkey for zuzax.com and I can create a subdomain under my control as an attacker, phish.zuzax.com, I can get you to sign a replayed challenge.)

Beyond my device, where the keys are stored determines their safety against theft and abuse. Using hardware U2F tokens, like a YubiKey or SmartCard, ensures the keys are locked to that device and cannot be extracted and physical theft is the only practical option. Some hardware tokens require a biometric, PIN, or passphrase to unlock as well. With the advent of passkeys, the secret keys can be synchronized across your OS vendor’s cloud (iCloud, Google Drive, OneDrive) or through your password manager (Bitwarden, 1password, etc.) making them more susceptible to theft if your account is compromised.

And, of course, it has to be implemented. The burden of implementation lies with the sites (where we have made reasonably quick progress on this in the past year) and, as ever, with enterprises that must enable and use it in their specific environments. This isn’t so different to our constant advice to security practitioners to treat MFA as basic hygiene (along with patching and disabling unnecessary RDP), but it still has to be budgeted for and done.

The last remaining weakness is the session cookie that gets set upon login, but that’s a topic for another article.

It goes both ways (and moves us forward)

As a user, I should be able to prove my identity to my device by using a PIN, fingerprint, or faceprint, and have the device do the work of authenticating both parties. That’s the most important part of this transaction — its bidirectionality.

We all know password theft is a problem, and we have really only extended their lifetimes by trying to augment them with other flavors of knowledge-based authentication. Information can be and will be stolen, intercepted, and replayed. If we truly want to have multifactor authentication, we must move beyond knowledge and demand stronger proof.

This is an opportunity to move beyond security being a source of friction for users; in fact, it actively improves security while diminishing the friction. Today’s passkey implementations can be finicky and awkward, but I am convinced those who embrace it will benefit the most and that in short order we will solve the user interface challenges. We don’t have a choice. It is the best solution available to us and the criminals won’t wait for us to argue the merits.