March 14, 2023

Are authentication factors still useful?

This newsletter's topic is around authentication factors and multi-factor authentication (MFA), and whether these are still relevant concepts to think about in 2023. On the way, I discuss newer technologies like passkeys and how they are pushing even further against these terminological boundaries.

Authentication Factors and MFA

Most developers at some point will have come across the three "factors" used for authentication:

• Something you forgot so you wrote it down on a sticky note (and then lost).

• Something you left at the office.

• Something that's covered in glue/jam/sweat/gloves/sunglasses.

The standard mantra of secure user authentication for many years has been to require two-factor authentication (2FA) or multi-factor authentication (MFA). There are many reasons for encouraging MFA, but these boil down to two primary security benefits:

• Different factors have different threat models. Passwords are easy to guess and vulnerable to phishing, whereas hardware security keys are not. On the other hand I've never accidentally left a password in the pub or on a train.

• Multiple factors provide some defence in depth. A critical security vulnerability might allow trivially bypassing one factor, while the others remain secure.

Over time, these categories have become increasingly blurred. Very few security professionals recommend actually remembering passwords. They instead suggest using a password manager to remember them for you. (Just not that one...). So in that case, is a password something you know or something you have? If you need to type in a master password to unlock the password manager, does that count? I unlock my own password manager with a fingerprint scan, via Apple's TouchID—does that make the password manager now a biometric authenticator? Does my password now count as MFA?

(Perhaps my password manager is part of my extended mind? The crisp distinctions of authentication factors are, at least, somewhat philosophically naïve.)

Similar questions arise around the use of more advanced authentication technologies such as FIDO/WebAuthn. Originally, these were deployed to provide MFA in addition to a password, although you could use them as a single factor. However, with the introduction of passkeys by Google and Apple (which build on top of WebAuthn), there is an increasing desire to throw out passwords entirely and rely on just the passkey as the sole method of authentication. This is sometimes called passwordless authentication. Passwords have many well-documented problems, so this is attractive.

For the vast majority of users, who don't enable MFA, passkeys a clear improvement. They are unguessable strong credentials based on public key cryptography, and they are much less susceptible to phishing attacks. But for users that were already using MFA, do passkeys (alone) provide equivalent security? Should I use MFA with passkeys? What if my passkey requires local biometric (or PIN) authN before it can be used? Does that count as MFA? These questions don’t necessarily have clear-cut answers.

Local authentication factors

If your website relies solely on a passkey for access, then this is a single factor of authentication on the face of it. Anyone that gains control over a user's passkey can login to your site as that user: the classic threat model of a "something you have" authentication factor. The security of this authentication then depends entirely on how well protected the passkey is. For this discussion, I will assume that the passkeys are stored securely by the user’s device/account (that is a whole other discussion), and instead focus on how hard they are to use if someone gains access to my device.

The WebAuthn standard provides two bits to indicate the level of user involvement when an authenticator was used:

• The User Present (UP) bit indicates that a user was physically present when the authentication response was generated. For example, my Yubikey requires me to press a button on the device to show that I am present.

• The User Verified (UV) bit indicates that the user was locally authenticated in some way. For example, by a fingerprint scan or entering a PIN.

In terms of threat models, the UP bit defeats simple malware attacks. If malware is running on a user’s device, it cannot simply initiate authentication requests in the background without the user's involvement: unless the user (or someone else) presses the button on the authenticator then the requests will be ignored. But if someone steals my Yubikey they can easily use it---the authenticator cannot tell the difference between me pressing the button and anyone else.

The UV bit provides a bit more assurance. It not only protects against the threat of malware, but also against an attacker who steals my authenticator device. They cannot use it without access to my fingerprint or knowledge of my PIN. UV implies local authentication.

Does UV count as MFA?

Whether a UV check provides MFA depends on how you look at it. From a user-centric threat model perspective, you can say that it does: a security key or device (something you have) with fingerprint scanner (something you are) addresses a stronger threat model than a security key with just a presence check button. But at the end of the process, the security key will still send a single cryptographically signed message to my webserver as proof of authentication. If there is a flaw in the device's implementation of this signature, or a flaw in my verification of it, then an attacker may be able to trivially bypass the whole process regardless of how many factors of authentication the security key implemented locally.

So you get protection from different user threat models, but less defence in depth than “real” MFA.

Do you trust the authenticator?

Another aspect of this is that even if the authenticator indicates that user verification has occurred, this may not actually be true. If the device is insecure and an attacker compromises the private key, they can set the UV bit to whatever they want. A faulty or badly implemented authenticator might just set the bit incorrectly. As a relying party (in WebAuthn-speak), why should I trust an assertion of local authentication from some random user-chosen authenticator device?

In a closed ecosystem you could use attestation to restrict device registrations to only models and manufacturers that you trust, just as many websites only allow federated login with a small number of trusted identity providers. However, on the open web, mandating particular hardware requirements to access a website is extremely problematic to say the least. Adam Langley has written persuasively on this topic.

Does it matter?

Ultimately, should the RP even care whether or how the authenticator implemented additional local authentication factors? This is a broader question that really depends on what authentication is being used to do. If, after authentication, the user only gains access to their own resources that they previously created (as in many websites), then it probably doesn’t matter too much. By all means, provide guidance to users about strong authenticator devices, but that’s probably enough. (However, note that this is not the case for social networks, where users also gain access to other peoples’ private posts and photos).

However, if the user gains access to more privileged material after authentication, for example because of their job role, then this suggests a more careful analysis of threats and mitigations. In this case you may care a great deal about the level of local authentication assurance provided by an authenticator device.

Conclusions

Ultimately, I think the terminology of authentication factors is becoming less and less useful over time due to the blurring between factors and the increasing complexity of modern authentication setups. Instead we should spend more time thinking about the nuances of specific threat models and failure cases, and designing our login processes to be robust against a broad range of failures. This design process should consider authentication factors, but only as one part of a broader approach, including robustness against failure cases, defence in depth, and alternative signals of user identity. Not to mention user experience and potential for abuse or harassment.

For me, the biggest drawback of an authentication factor-led approach to authentication design is that it hides that there are huge differences in security between implementations of the same factor. For most users and services most of the time, passkeys are an enormous security improvement over passwords. Most of this security improvement has nothing at all to do with what kind of factor they are, and everything to do with the careful consideration of threat models and real-world security that has guided the development of passkeys.

Applied Crypto and AppSec news roundup

• Soatok delves into the murky delights of database encryption. tl;dr it’s more complicated than you think. (My general advice is to get really comfortable with your DBMS’s access control features before even thinking about cryptography).

• I wrote a book review of a little gem of a cryptography textbook.

• Scott Helme wrote a good post about improving the password security of the Report-URI service. This covers a lot of good nuts-and-bolts improvements to password security and is worth a read.

• A memory safety bug in the widely-used reference implementation of SHA-3 was discovered that can be used to perform remote code execution (RCE), and (amusingly) also “break" the preimage resistance of the hash function.

Spotted some interesting news that I missed? Please contact me and let me know for next time.