Passwords have been around a long time. They are ubiquitous. But does anyone really like them?
Users don’t like them. Developers don’t like them. Companies spend millions of dollars every year working to prevent password compromises. Worse, many companies suffer password-compromised attacks from hackers, resulting in millions of dollars in losses and bad publicity. Over 80% of all security breaches are the result of a compromised password.
Despite the increasing sophistication of password-based systems, it's just hassle and risk and no fun wherever you turn.
But fortunately, there is a way forward. In this series of articles, I’ll talk about why passwords are problematic and then discuss what is being done to allow us to move past passwords into a passwordless – and vastly more secure – future.
Password technology has actually come a long way. I’ve been around long enough to remember when the only way people would protect things on the Internet was with Basic Authentication. Here’s how it worked according to Wikipedia:
In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where credentials is the Base64 encoding of ID and password joined by a single colon (:).
Given that Base64 is an encoding and not encryption, you were basically sending the information in the clear for anyone to see. Using it with HTTPS can help, but in the end, Basic Authentication was, well, useless. Naturally, bad guys soon made Basic Authentication pointless.
So next, websites started implementing their own authentication, storing usernames and passwords in their database. This of course meant that any rogue employee could see your password, and that hacking the database meant access to every user’s password in plain text.
Then the good idea of hashing and salting passwords for storage came about. Hashing and salting provides a one-way, unique encoding of your password, allowing sites to store the result, repeat the process, and compare the results when you login. It works well, and the site doesn’t end up knowing your password.
With this, hackers started doing “phishing,” or tricking users into typing their credentials into convincing but fake websites.
The next step was multifactor authentication (MFA). You are likely familiar with this. It is the process of providing more information than a password – something you know and something you have – to the authenticating entity, typically a token – very often that six-digit number from an authentication application.
Currently, this is the de facto standard for authentication. MFA is effective at increasing the security of user accounts. However, phishing attacks have gotten more sophisticated, and even authentication processes involving MFA can be hacked.
In the end, even with our best efforts to make passwords safe and secure, passwords remain a significant attack vector for bad actors and a hassle for users, IT departments, and developers.
Our users – who, remember, are very often our customers – have to take an active and often challenging role in the whole password process. We put a lot of the burden for security on them, and they don’t always take it seriously. We end up trusting them to protect access to our resources.
Good password hygiene is difficult and tedious, and people very often don’t follow all the rules. Many reuse passwords across different websites. (Be honest, you have very probably done this, right?) Some use easy-to-figure-out password variations. Others even use passwords that are shockingly simple to guess like “password123” or “qwerty”. They don’t change their passwords from the default. They write them on sticky notes attached to their monitors. They let password-stealing malware get installed on their computers. The list goes on.
And as password management becomes more complex, users have to turn their attention away from where you want it. They end up having to go to a separate application, logging in there (if they can remember that password!) and then coming back to your site with their password. Or with MFA, they have to leave your website to retrieve a timed token from an authenticator application or a text. Either way, it’s a bother and an attention diverter.
And of course, all this creates friction for your users that can deter them from accessing a website. All of us have probably looked at a long list of esoteric password requirements and abandoned our attempt to register. Too strict, and users don’t like it. Too simple, and you risk compromise. And nobody wants to make things tough on customers.
Authentication is always a concern for developers. While many choose to roll their own solutions, there is always the risk that their level of expertise is not up to the task of filling every crevice and corner case.
In addition, pre-packaged solutions exist for most frameworks. This type of solution is usually a safer bet, but developers always don’t know all of the implementation details, meaning they can’t be sure that a configuration change doesn’t create a security issue. And a password-based system, no matter how well implemented, still remains vulnerable to the risks outlined above.
We’ve talked about the vulnerabilities of passwords. Another important thing to note about passwords is that they really don’t scale. When your user base is small, the attack surface is small. But the more customers log into your site, the more likely it is that one of them will make a mistake and get phished. In addition, the more users you have, the more effective a password spraying attack becomes. Growth is good, but with increased growth comes increased risk.
In the end, passwords don’t make anyone happy. The difficulty of proper password use, the surprising ease with which passwords, and even MFA, can be compromised, as well as the friction created by common authentication methods all make for a system that is ripe for disruption.
Someone ought to do something about this, don’t you think?. Good thing someone has.
Coming next: WebAuth and Passkeys
Check out our resources to learn more: