Going Passwordless (AKA: Should you kick that disgusting habit?)
First of all, let's dive a little into the reasons for this sudden hype of a concept that has actually been around for more than 15 years.
What's wrong with passwords?
Passwords. They are the most primitive means of authentication out there, right?
Wrong! In fact, passwords are (originally) not a method of authentication at all.
The first method of authentication ever used was actually biometrics. Face recognition, specifically. Humans have been using it for as long as we exist.
Hello, Bob! I know it's you, because I know your face!
That's what we did, for thousands of years. We recognize that a person is Bob because we recognize his facial (or other) traits and associate them to his identity. At some point, however, identifying anyone based on their face alone becomes impractical, because we humans can only accurately remember and identify so many faces. So other methods were invented. We will explore this amusing story in later articles, though. Let's go back to passwords.
Passwords were actually not invented for authentication, but for authorization. Knowing the pass-word, would not provide any information about who I am, but would let the gatekeeper know that I'm to be allowed entrance to the club or the secret society meeting.
Centuries later digital authentication was implemented via a password which is shared not with multiple unknown individuals, but with only one (me). That way, passwords just went from an authorization to an authentication mechanism.
The problem with passwords has been the same throughout history, though: They are shared with whom they shouldn't be. Leaking the password will give the bad guys access to the heroes lair, and they will only find out once it's too late.
In fact, more than 85% of data breaches and security incidents are caused by poor, reused, default and stolen passwords. And what do we, security practitioners, typically do about this? We devise strong password-complexity policies, which aim to make them more difficult to guess and frequently rotated in order to reduce the impact of leaks. I recently watched a fun video which I somehow managed to understand as a metaphor for the effectiveness of password-complexity policies (I could not find a suitable version to share here, so a description will have to do):
- A cat owner decides to put his cat flexibility to the test.
- In order to do this, he places two cardboards at each side of the room door.
- Each time the cat crosses the door, the owner brings the cardboards closer together to see if the cat will still be able to fit through.
- Impressively enough, the cat manages to make it every time, until the cardboards are just 5 cm apart.
- At 5 cm, the cat has had enough of this nonsense, and simply jumps over the cardboards into the room.
This is the exact reaction password-complexity policies tend to generate in our users. "Password needs letters and numbers", "Password needs special characters", "Password needs to be changed every 12 months", "No, every 6 months", "No, every 3 months". In the end, the user jumps over the cardboards:
Post-its under the keyboard, documents with a list of all used passwords, single password across all personal and professional accounts, adding Month+Year to the Password to rotate it without actually changing it... Sound familiar?
When we make it too difficult for users to maintain their passwords, not only are we not improving security and increasing only the friction for them, but we are actually making a leak more likely, since we put the user in a situation in which one compromised password gives the attacker the keys to the kingdom.
After all, any given person has (whether they are aware of it or not) up to 85 passwords in different sites and service providers. Can we really blame them for not remembering 85 different ultra-complex and totally-random passwords? If users tend to reuse passwords across all accounts (and, let's face it, 99% of them do), any of these passwords is only as strong as the weakest of them all. If the website for buying and selling vintage baseball cards that I registered in 5 years ago (and then forgot) stores passwords in plain text (without encryption) and gets hacked... oh boy. To be perfectly honest, it's not really even their fault. It's not really ours (as security practitioners) either. There simply was no better option. Yet.
What is passwordless?
As the name suggests, passwordless is a new Authentication paradigm where passwords are not needed, and instead users are asked for additional factors to prove their identity (MFA), such as their fingerprint, a code sent over SMS, etc.
How might this look like? I access my laptop one morning. A login screen pops up. I introduce my username and click "access". I see a message which says "please check your phone". I do, and there's a push notification, asking me to provide my fingerprint for authentication. I do, and my laptop logs in. Done. An attacker would need to steal both my phone and my finger to be able of impersonating me. This is only one possible passwordless MFA scenario. We will dive deeper into MFA in future articles.
However, there are a lot of talks about "going passwordless" which tend to over-simplify what it means, creating confusion and misunderstandings. To clarify, when we say passwordless we might be talking about 4 different things:
- Your domain is truly passwordless. This means that the user accounts don't even require a password to be set. The is no password. Therefore, they cannot be exploited. The software itself needs to allow for this. While some applications might have managed this individually, I doubt that a lot of organizations have, and for sure none of the more complex ones using hundreds of corporate applications.
- You offer a passwordless experience. Ok, so you have traditional applications, most of which do require passwords. But users never use them. They don't even know them. They just use Multi-Factor Authentication to access everything. Because your applications use passwords per account, they can still be targeted by attackers and exploited. In other words, they represent an attack surface. Therefore, you set passwords to be incredibly complex, random, and rotate every 24 hours, for example. Since nobody is going to use them, you don't really care that they are unusable. In fact, that's what you're after.
- You have some form of passwords, but you don't necessarily use them. You rely on Multi-Factor Authentication, with passwords being one of these factors. And they're never used in isolation. So even leaked passwords have no risk by themselves without an additional second factor. Users can decide to not use passwords entirely, even though this is not a passwordless scenario.
- You use passwords as a fallback mechanism. Users don't typically use passwords. Not on a daily basis. They use Multi-Factor Authentication to access everything... until they can't. When they lose their phone and they need to configure a new one for those push notifications, they are required to provide their password. So they must have one. And they must remember it. This is not passwordless. In fact, it's very dangerous to think that we can drop password-complexity policies altogether, in this scenario. Because those passwords now represent an even bigger risk factor than before (since users will very often forget them, for lack of use). In fact, when users do need to use them and have forgotten... what's the plan? Requests to the IT Support team to reset the password? What is the IT Support team going to do to validate that the request is in fact legitimate and that they're not resetting the password for the attacker?
The contradicting conclusion
While I believe there is no question that passwords are outdated and insecure mechanisms and that we now have much better, more usable and secure alternatives, it's also true that we are still in a transitioning phase, where it's still a challenge to achieve the above option #2, and almost impossible to achieve #1. But it's an evolutionary process, and there are definitely very powerful MFA alternatives that allow us to drop, at the very least, our dependency on strong and little-effective password-complexity policies and advance towards the future.