What the Factor?
Stop thinking about authentication factors. What matters is the quality and properties of the protocol, not the factors it invokes.
You’ve heard of multi-factor authentication (“MFA”), or two step verification (“2SV”). You may associate this with a security key you plug into your USB port or a code from your phone you have to enter alongside your password. Your security team at work and your tech-conscious friends keep nudging you to turn MFA on and use it. But what does a “factor” mean in this context, and why are they important?
Factors are an abstraction imagined by ancient computer scientists, not a useful way to think about account security. What really matters is the quality of the authentication protocol you’re using to sign in to a site. A password alone is a terrible authentication protocol because you know your password, the site knows your password, and you enter the whole password every time, creating lots of opportunities to steal it (like phishing). When you use a password and a one-time-code from your phone, the important thing isn’t that there are “more factors” involved (there aren’t, not really). The important thing is that password+code is a better protocol than password alone. But the best protocols are the ones specifically designed from the ground up for authentication in the sort of world we currently live in. These protocols (the flagship of which, right now, is called Passkeys) use fancy cryptography to implement the best possible authentication system we can imagine, while minimizing work and complexity for the person using them. Trying to describe these protocols in terms of factors is difficult, because factors are the wrong way to think about authentication protocols. Authentication protocols are designed based on the technical properties they should have: a complicated way of reasoning about how they defend against which sorts of attacks.
If that’s all you needed, congratulations: you are now and forever liberated from having to think about factors; go in peace. If you want a little more meat than that, read on. If you understand but are now worried because you have to comply with a policy which talks about factors, skip to the end for one weird trick (auditors hate it!).
What are Authentication Factors?
In the ancient era when the dozen or computers that existed each filled entire rooms, wizened techno-philosophers theorized and prognosticated about what it really meant to sign in to accounts on computers. They came up with the theory of “factors”, where a factor is one way that you can prove to a computer that you are who you’re claiming to me. They imagined “knowledge factors” like passwords (“a secret that you know”), “possession factors” like keys (“an object that you hold”), and “inherence factors” like biometrics (“a measurable property about you”). This became an abstract academic theoretical framework which tends to be repeated verbatim in computer security classes to this very day.
But this framework isn’t really true; this is not how computers actually work. When you sign into an account, you’re never presenting yourself in person for inspection. The only thing you can send to that remote computer is information. In the world we live in, everything is a knowledge factor, even if we sometimes try to make it look like a possession factor by locking the secret up inside a security key. But serious computer security experts who know what they’re talking about still talk about the importance of multi-factor authentication — why?
So-called multi-factor authentication isn’t an improvement because more factors are better. The improvement is that most MFA sign-on procedures are better authentication protocols than passwords. The problem isn’t that there aren’t enough factors; the problem is that passwords suck.
Passwords Suck
When you sign in using a password, you send the whole password to the service you’re using. You need to come up with that password, you need to remember that password, and you need to make absolutely certain that you only ever enter that password in the right context, and not the wrong one. There are a few problems with this security approach.
Top of the list is phishing. Humans are, in general, not very good at telling the likes of goοgle.com (a legitimate domain name) from go0gle.com (a phishing site pretending to be google.com). In fact, you just got fooled! That first domain uses a Greek omicron instead of the second “o”. Any site which gets your password this way can use it to sign in as you forever (or, at least, until you change it). We might say that passwords can be replayed.
Another problem is data breaches. The site you log into has to store a representation of your password. If their authentication database is leaked, someone with enough time and computing power can make a lot of guesses as to what passwords might be in the database. And if they work out a person’s password, it’s very easy to try that password on other accounts which might belong to that person. You know that you’re not supposed to use the same password multiple places, but you’re also supposed to floss daily and test your smoke alarms twice a year. (Sites can make it harder to crack their password databases, but that just makes this process take longer, from days to weeks, rather than making it impossible.) We could say that passwords are reversible, but not website-bound.
There are other problems with passwords! Passwords have so many problems, and I’m not going to describe all of them here. But these three problems (replayability, reversability, and site-binding) are enough to show what I mean.
A Better Protocol, Not More Factors
A common MFA protocol involves your phone generating a code which changes every thirty seconds. Your phone does this by combining a secret with the time to work out what the current code is. The website also knows the secret (that’s what was expressed in the QR code when you set it up) and the time, so the website also knows what the current code should be.
When you enter your password and this code, you could think about this in terms of factors: a knowledge factor (the password) and a possession factor (knowing the code means that you have your phone). But that’s not really true. You can scan that QR code with your password manager, or take a screenshot, or do any number of other things which let you have the code without having your phone. And if the password was randomly generated by your password manager and you haven’t memorized it, is it still a knowledge factor, or are you proving that you “possess” access to your password manager? If you password manager autofills both the password and the code, does that become one factor rather than two? It’s a mess. This is the wrong way to think about what’s happening.
A better framework is that the password plus this sort of code is a better authentication protocol than a password alone, because this protocol is much less replayable (it would have to be replayed basically immediately, and not five-minutes later) and is website-bound (the code you get for one site won’t work on another). This protocol is still reversible, though, because if the website’s authentication database is stolen, the secret used to generate that rotating code goes with it. But at least the database thief can’t use it on another site.
Better Protocols; Best Protocol?
I tried to show that using passwords alongside a code generated on your phone is an improvement, but not perfection. That’s because the properties I picked for this example are only a simplified subset of the elaborate universe of authentication. There are lots of properties that authentication protocols might have. There are plenty of potential attacks and countermeasures. There are practical requirements that you should be able to sign in using multiple devices under a variety of circumstances. This isn’t supposed to be an authentication textbook, so I won’t add any more detail.
There’s been a lot of work on authentication in the 2010s and 2020s. Moving from high-quality password managers, to adding one-time codes, to the development of security keys and WebAuthn, and now Passkeys. These represent the best we know about how to design a secure authentication protocol. They represent an incremental shift from passwords imagined and typed by humans to purely machine-to-machine negotiation using cryptography. Are Passkeys the best we’ll ever manage? Who knows. But they’re a phenomenal step forward from passwords.
Compliance Concerns
(If you don’t have to comply with a security standard which uses the word “factor”, you can stop reading now.)
Let’s imagine that you’re with me up to this point, and are now sweating bullets wondering how you’ll be able to tell an auditor that you use multi-factor authentication now that you possess the ｆｏｒｂｉｄｄｅｎ ｋｎｏｗｌｅｄｇｅ that factors aren’t real and can’t hurt you. Maybe you’re worried because you read the WebAuthn or Passkeys specs and think that they really sound like they’re reducing authentication to a single “factor” — a cryptographic key.
I have good news. These sorts of security policies are talking about what the human operator needs to do to be able to access and use that cryptographic key. Need to unlock your phone to use a Passkey? Great, that’s a knowledge (PIN) or inherence (biometric) factor, plus possession of the phone. I’m sure you can work out the factors which apply in other scenarios. Auditor or security officer still looking skeptical? For a small donation to an appropriate charity, I will write you an expert report saying that there are enough factors around a Passkey or WebAuthn credential to comply with your policy.
Credit & Other Sources
I am not the first person to say this; this is not a novel idea of mine. I am sure that others have said it before now, and better. But I haven’t found another place that this concept was conveniently written down and easy to share. That’s what this post is supposed to be!
Here’s at least one other place that this concept has been expressed:
Do you know about another place someone has explained this? Let me know and I’ll add it here.
