Logging in, a thing we all hate

We’ve all seen this one, right?

“As a user, I want to log in to the app.”

That’s a lie. And not just a little one—a whopper. Logging in isn’t on anyone’s to-do list. It doesn’t put anyone closer to their goals. It doesn’t create value and it doesn’t provide a service. Logging in, like locking your front door, isn’t something you want to do. It’s something you’re haplessly forced to do because there’s no safe alternative. It’s meeting a problem you’re not interested in with a solution you didn’t ask for. And it’s creating other problems in spades.

The login form

I built and maintained a cloud-based writing app from 2018-2021. Over that period of time a few thousand people logged in. Now, logging in wasn’t the point. It wasn’t supposed to be a big deal. It was as simple as it could possibly be: an email address and a password (no labyrinth of password rules here; 12 characters or longer and you were good to go). I built the signup/login/password reset flows by hand and tested them exhaustively.

During those three years, I received fewer than 10 customer support emails about the relatively complex “writing” part of the app. Occasionally there were bugs, of course, but they were rarely disruptive. However, I received dozens of support emails about the login page, which consisted of two text fields and a button! For example:

• Sometimes people misremembered or mistyped their password several times in a row.
• Sometimes people mistyped their email address when they were signing up, so they never got their account verification email. It got to the point where I had to ban spaces in the “email” field because so many people were typing them by accident.
• Sometimes people capitalized their email or password when signing up, then typed them lowercase when logging in. (Passwords are case sensitive on every single website in the whole universe, but I digress.)

In all of the above cases, they blamed the app for something that was 100% user error. But can you blame them? The world is chock-full of cheap, broken software. I’ve encountered more than a few buggy login pages myself.

The ugly truth of the matter is that logging in—the very first part of interacting with a software product, something on which the entire experience depends—is often more complicated and fraught than anything else the app does. It takes more effort to get into the app than to do the thing you want to do with it. It’s a hazing ritual, a thorn in your foot, a mild annoyance on top of the hundreds of others you have to cope with just to exist online.

Is there a better way?

Trust (yeah, right)

The reason you have to log in is so that no one else can pretend to be you, right? Imagine for a moment that we could trust all users to log in as themselves. No passwords, no tokens. Tell us who you are and you’re all set.

A couple of apps do this. For example, if you join a Zoom meeting as a guest, it’ll ask for your name and display whatever you type. Or if you’ve ever played Fibbage or Quiplash (delightful party games from Jackbox Games), you likewise join by entering your name, which isn’t verified in any way. This is appropriate UX for contexts where you don’t own any persistent data and the risk of misidentifying you is relatively low.

But even when there’s no asterisk-masked password input, people struggle. They misspell their own names. They don’t see the “Name” input at all and tap repeatedly on the “Start” button, bewildered, until someone helps them. When they finally pass the login screen they decide they’d rather go by a different name, so everyone waits for them to sign out and sign in again. Even without passwords, logging in is a comedy of errors.

Emails are even worse than names. Most people don’t understand how an email address works, semantically; it’s just a block of text they have to memorize, like a password. And you can’t assume the average person remembers which address they signed up with—the average email user has 1.75 addresses, and I’d guess the number is much higher for my generation than my parents’. Personally I’ve got hundreds of email aliases. If it weren’t for my password manager, I wouldn’t even be able to request a password reset from most of the sites I use.

Usernames and emails are a mess. Unfortunately, they’re only half the mess. A password-free login isn’t realistic for most commercial apps. Any time users are creating things, bookmarking things, or reacting to things—even under a pseudonym—they’re very averse to the idea of being impersonated. Not to mention the material harm that results when someone does impersonate you, worst of all when your credit card or government identification number are at stake.

SSO

Single Sign-On (SSO: “Sign in with Google,” “Sign in with Facebook,” etc.) is theoretically more convenient and secure than an email-password login. Your identity resides with the SSO provider and they provide tokens to registered third-party APIs so you can access multiple apps after logging in once. In my experience, though, it’s not a whole lot better.

Maybe I’m alone here, but if your site has more than one SSO option I’m gonna have no idea which one I used to create my account. I’ll stare blankly at the login screen for a few moments, pick an option at random, and hope for the best. If the SSO provider asks for permission to share my identity, I’m going to assume I picked wrong, close the tab, and try a different one. Then rinse and repeat until I decide it’s not worth the trouble after all.

I’d rather use a password.

Slack has an interesting approach to this: when you sign in, you type your account email and they send you a “magic sign-in link.” The link has a token in it that grants access to the app. It’s a cross between SSO and resetting your password every time you log in. This certainly isn’t worse than what anyone else does—your email account is a single point of failure for your entire security network, generally speaking—and in terms of UX it’s excellent, since most of Slack’s user base is signed into their email account 24/7.

But whether we’re talking about SSO or magic links, we’re talking about little more than passing the buck. This isn’t solving the problem. It’s saying “hopefully someone else is doing this better than we are.” It’s saying “remember Facebook, that paragon of security and trust? We’re going to let them tell us who you are.” It’s putting all your eggs in one basket.

Biometrics

Face ID is (mostly) a joy to use. All I have to do is hold up my phone. It scans my face with an infrared camera and lets me in if it thinks I’m me. And by default it requires me to actually look at it, so no one can let themself in while I’m asleep.

My last phone had a fingerprint reader. It sucked.

The infosec community, from what I’ve observed, is skeptical of biometrics. They say “fingerprints are usernames, not passwords.” They say “fingerprints are half-secrets that can’t ever be changed.” And their reasoning is sound: a fingerprint, like a password, is just a series of bits sent over a wire. Those bits can be sent by anything, really. The other end of the wire doesn’t know where they came from. So if someone has your fingerprints (or, in the case of Face ID, a picture of your face) and the right equipment, fooling the biometric login is almost as easy as Mission Impossible makes it out to be. And there’s no putting the genie back in the bottle—you can’t “reset” your own skin.

Perhaps the greatest danger of biometric authentication is that it seems secure. We grow up hearing over and over again that everyone’s fingerprints are unique and no two faces are exactly the same. And since we recognize each other by our faces, we intuit that it’s okay for computers to do so. But “unique” is not the same as “secure.” When we treat something insecure as if it were secure, we’re prone to neglect more important things. The illusion of security only makes a lack of actual security more dangerous.

Location

Both my current and previous phone have relied on a PIN number as a backup method of access. This is an interesting contrast to the “passwordless login” method. The phone itself is the username (as long as I don’t do a factory reset). It represents a single, static identity more or less permanently. So this is username-less login: all we need is a password. But even if it didn’t have a PIN or biometric authentication, even if anyone at all could pick up my phone and use it, it would be more secure than most of my online accounts because it requires personal, physical, on-location access. I don’t have to worry about scammers all across the world trying to steal my stuff; I only have to worry about anyone who comes within five feet of me. That’s the kind of security CTO’s dream about.

Of course, most of my data isn’t stored exclusively on my phone’s solid state drive. There’s still plenty to keep me up at night. But it’s nice to know that my phone, for whatever it’s worth, is a relatively small risk.

Google and a few other identity providers simulate this by using location as an added layer of security. If I’m traveling and try to sign in from a new location, I have to authenticate via a second factor like a notification on my phone or a trusted contact. And thankfully, this can’t be circumvented by VPN or location spoofing because signing in from a new device is treated the same way.

Location and device checking is a nice security feature. But it obviously can’t replace passwords. Not just because other people could use the same device or exist in the same location as me, but because I sometimes go to other locations and use other devices.

Password managers

I use a password manager and recommend it to everyone. There’s really not a better way to use strong, unique passwords across the entire internet without ever locking yourself out—though it could be argued that the oft-maligned “sticky note on your monitor” method is more secure in some contexts than the “encrypted password vault accessible from anywhere in the world” method. Regardless, password managers are what security experts recommend and I’m happy to defer to their expertise.

Password managers have two serious flaws.

For one, practically no one uses them outside of IT, and we IT folks are more security-conscious than our peers anyway. So password managers are like a hospital that only admits the healthy: they help those who need it least, which makes their value in the real world questionable.

Second, they don’t actually solve an essential problem. They solve a problem created by the solution to a different problem. That is, if security is the problem, then passwords are the solution and forgetting your password is secondary to it. Password managers are two steps removed from the issue, part band-aid and part hasty justification for a solution that’s insufficient in the first place.

So while they may be an essential tool for anyone who cares about online security, they’re not a solution to the problem we’re discussing here.

Hardware authentication devices

If you’re looking for something even more unpopular than password managers, look no further than YubiKey. Outside of government and Big Tech most people have never heard of hardware auth devices. They’re a good idea in theory, even when they amount to little more than a USB robot-keyboard that types a one-time password for you, but they’re a hard sell for the average user.

On the other hand, pretty much everyone has one in their wallet: the NFC-enabled microchip in your credit card. Chips are more secure than credit card numbers and magnetic stripes because they can perform computations on the fly, allowing them to do live cryptographic exchanges at the point of sale (true story!). Credit card numbers are easily stolen but a private key is just about bulletproof, especially when the user doesn’t know what it is and their microchip is engineered not to divulge it.

If you could use a credit card microchip as an authentication device, you’d be in security paradise. Your “password” would be unforgettable, nearly unhackable, and vulnerable only to physical theft or damage. You couldn’t give it away to a scammer over the phone even if you wanted to. It would expire and be replaced after a set amount of time. And since everyone knows to call their bank if their credit card gets stolen, mitigation would come built in. Almost all the security risks would be shifted to the bank’s credit card cancellation and issuance department, and they’d have to try pretty hard to be worse at it than the average consumer.

So yeah, it would be awesome to use your credit card microchip as a password. There’s only one problem: you can’t. Most computers don’t have NFC chips. And even if they did, we’d have to convince banks to act as SSO providers to some extent, which they may or may not be interested in doing.

Passwords

So now we’re back where we started. At the intersection of security, portability, convenience, and ease of implementation is the password. It seems it’s a necessary evil. But make no mistake: for all its necessity, it’s very, very evil.

The nature of the password encourages failure. Most people outside the tech industry are far more worried about forgetting their password than having it stolen. How could that be, when the consequences of the latter are so much more severe? The reason is twofold. First, getting hacked is like getting mugged or having your house torn apart by a hurricane: it’s extremely easy to tell yourself it won’t happen to you. After all, it’s only happened to other people so far. And second, people forget passwords all the time. Go check your mom or dad’s Facebook feed, there’s an abundance of memes about it. AJR even writes lyrics on the subject. It’s a threat that never feels distant. So that’s the one people take seriously, and they respond by either using one password for everything, from Chase Bank to Club Penguin, or keeping a rotating list of three or four equally weak passwords, which really isn’t much better.

The bottom line: every password exists on a spectrum from “weak and convenient” to “strong and annoying.” And we should not expect user behavior to trend toward “strong and annoying” just because it’s the right thing to do. Anyone who studies human behavior at any scale will tell you, without hesitation, how that story ends.

Of equal importance is the fact that a password doesn’t prove anything. At best you can hope it was typed by the person who created it, and you can further hope that person is who they said they were. But it might have been snapped up in a massive retail hack or phished by an SMS scammer. It might have been brute-forced or typed from a country where the user has never set foot. A password is not a cryptographic conversation and it has no connection to an identity. It’s more like a second username that we act secretive about because we don’t really know what else to do.

What’s the future of auth, then? I desperately hope it isn’t a tale of ever-longer passwords and more rounds of hashing. That cat-and-mouse game isn’t working for anyone. If I had my way, it would be a combination of biometrics (replacing the username field) and an NFC microchip with an asymmetric key, preferably the one on my credit card right now (replacing the password field). And if the good folks at Apple or Twitter or Wells Fargo want to throw some location- or device-based verification on there, so much the better. I know the technology isn’t ready yet. But it’s on its way.