Preface
I am no security expert, this is only accumulated research that I have done to the best of my abilities.
This is a very broad overview on our assessment of authentication, among other things, in Cosmicverge and our other projects. Other requirements and needs exist that might not be covered here, this is an extensive and varied topic.
Passwords
It is common knowledge nowadays that authentication can be a problem, remembering good passwords, storing passwords, account recovery, password re-use, there are many problems the common user has to contend with nowadays.
To all these problems come many solutions, password managers, password generators, security questions, human or machine support for account recovery, password strength calculator and many more.
All of this leads to the conclusion, by many experts, that passwords are just not a good solution to the problem of authentication.
When @ecton and I discussed authentication for Cosmicverge, we agreed upon the same conclusion.
There are many alternatives to passwords, I will go through each one and assess them. But before that, we should figure out what exactly we are trying to achieve here and attempt to cover related topics.
Authentication
Also commonly known as login, the problem to be solved here, is to ensure that the person that registered the account, is the same person that is trying to login.
What we are trying to protect against is impersonation. To put things into perspective, we have to understand what we are up against.
An interesting analogy I once read, is to imagine you want to protect your home’s door against a burglar, a good measure might be to install a good lock. This might be safe enough, because if somebody wants to break into your home, they actually have to be physically present and make a physical attempt to pick that lock, if your door looks safe enough, they might not even attempt to break in.
There is simply a physical limitation an attacker has to contend with, so unless there are enough attackers out there, the chance that your home will be attacked is already low.
On your side are:
- Distance
- Psychology (doors can look much safer then they are)
- Crime rate (almost all places on earth have less burglars then homes)
- Limited entrances (main door, windows, fence, …)
- Your Dog
This isn’t the case online, imagine your home has a door for each burglar that exists anywhere on the planet. Each door is more like a portal that leads exactly to the physical location of the burglar. Also, every burglar can build million machines that never tire, are never intimidated or afraid, that will attempt to break through your door.
Imagine you sit in your home, with an unlimited amount of doors that constantly rattle because somebody is testing if your lock holds up today.
No hacker out there is trying to “hack” you specifically (unless you are a juicy target of course), they just write programs that scour the internet for potential targets, potentially attempting millions of “hacks” every second.
With this perspective in mind, know that the most common password in 2020 was still “123456”. So how do we solve this problem?
Before we attempt to assess alternative methods to passwords, let’s discuss some goals and related ideas first.
Heuristic
Some basic heuristic during authentication are very common by now:
- Time-limit: how many wrong passwords you can enter before getting locked
- Location: comparing the current location against your last one
- Time: uncommon login times compared to your usual ones
- Device: using a different device
These are neither perfect or optimal, like the definition of “heuristic” says, but the biggest problem usually is privacy. So having users control this manually or solve privacy concerns otherwise will require some good ideas.
MFA
Multi-Factor Authentication is the idea of requiring multiple authentication methods to make sure that one compromised method, for example a leaked password, isn’t enough to compromise an account.
MFA has become very widespread today, it might be reasonable to assume that users feel comfortable with this idea at this point of time.
It’s also useful to keep in mind that it is desirable to keep authentication methods on separate devices if possible. First, this makes sure that one compromised device doesn’t lead to a compromised account, the attacker has to compromise multiple devices, secondly, it eases account recovery, which leads us to the next topic.
Account Recovery
Most authentication methods today use passwords (knowledge), smart phones in some way or another (possession) and maybe biometrics (inherent). These things can get compromised, stolen or lost. MFA will then lead to account loss if too many methods are lost. Even passwords aren’t fool proof, people forget passwords, or in the case of password managers, these can be compromised too.
This is an important problem to keep in mind when designing authentication systems, otherwise it would lead to a flood of support tickets that aren’t exactly straightforward to solve.
Going in-depth with account recovery is very project specific and is out of scope here. But it might be prudent to put protocols in place that moderators can follow in the case of an account recovery scenario. These protocols often are privacy unfriendly, so keep this in mind when designing these protocols and allow users to have some say on how account recovery might happen.
Generally speaking it is important to design MFA requirements in a way that makes sure that one lost method doesn’t lead to an account recovery scenario. Like mentioned above, one way to do this, is to ensure that authentication methods are on separate devices.
Attitude
When designing security systems like this, it is important to keep in mind worst case scenarios, for example compromised systems. This can happen on every level of the stack:
- Server Hardware
- Server OS
- Server Application
- Database
- Network
- Client Application
- Client OS
- Client Hardware
Another worst-case scenario to keep in mind, is if an attacker successfully impersonates someone, account recovery in these cases can be even more problematic, but it is important to prepare for cases like this and have protocols in place.
There is much more to consider here, like a malicious employee, compromised employee, deployment security and so on, but I will consider this out of scope for now.
UX
At the end of the day, we have to realize that the problem of user authentication, is very much a user experience problem. It’s simple to design an extreme system, for example:
- TPM-backed client certificate on the authenticating device
- Security key with WebAuthN or other asymmetric encryption method
- Confirmation on another device, like a smart phone, with a TPM-backed key
- Biometrics, like a fingerprint scanner on either the security key or smart phone
- OpenID Connect
- Require four out of five of these
To login, the user requires a device that has a TPM, have the security key plugged in and confirm the authentication on his smart phone with his fingerprint. As a backup or to migrate to a different device the user can use their Gmail account with OpenID Connect.
The obvious problem is that most likely your project doesn’t require this level of security, but whats the downside?
- Requiring the average user to buy a security key is usually not an option.
- Almost everyone possess a smart phone nowadays, but if your product runs on a smartphone, you might desire a second device. There are also plenty of users who don’t want to download a separate app on their smartphone because it’s a hassle or for privacy concerns.
- Biometrics are extremely rare outside of smart phones and like with security keys, it is usually not an option to require the average user to buy a fingerprint scanner.
- To this date most users don’t have a TPM on their desktop, requiring them to buy a new motherboard (maybe + CPU) or a TPM module and install it, is again, usually not an option.
So what are UX friendly options for the average user?
- Magic Link: send an email with a login link
- OAuth: login from an external OAuth provider
- OTP: a lot of users smart phones already have an app and it doesn’t require the user to divulge any private information, like a phone number
- OTP over SMS: it’s a good option as a second factor for account recovery, but has obvious privacy issues
- Confirm on separate device: basically a dedicated smart phone app to confirm login, as proposed above, the resistance against downloading apps has been lowered significantly in the last decade, but again, there are probably plenty of users who don’t want that, nonetheless it’s an extremely secure method akin to security keys
We will assess all these options and more in the next devlog, these are just some initial thoughts and suggestions.
Machine Authentication
Lastly, Before we come to a conclusion, we should note that authentication doesn’t only concern users, but also machines. This is important for many things, like deployment, automation, automatic tests, servers, clusters, databases, bot-based testing and much more.
This is very commonly achieved with the help of API keys, that may or may not be permission scoped. API keys have basically similar weaknesses as passwords, but they are usually guaranteed to be strong in complexity and size. They can still be compromised in many similar ways.
A lot of scenarios don’t allow for sophisticated protection like HSMs or TPMs. But there are still decent protections that can be put in place cheaply. For example using client certificates and using the OS keychain to prevent exporting. If asymmetric encryption isn’t an option, transmitting keys with OPAQUE or other PAKEs would at least protect against MITM attacks and, depending on the PAKE, protect against keys being compromised when the database has been.
Conclusion
This establishes, that in reality we have to balance three things:
- Security
- User Experience
- Account Recovery
To properly assess how we might balance those, we will have to determine some target groups and available methods to us. This is what we will cover in the next devlog.