I love simplicity. To a fault. If there’s a field (or even entire step of a process) that can be removed without sacrificing functionality, count me in. We implemented a passwordless login process for our e-commerce site about 8 years ago, mostly in the name of simplicity. The privacy benefit of not storing passwords was just an added bonus. But the current options for passwordless login are far from perfect, and, if you’re considering taking the plunge, you should consider the limitations and new challenges you’ll face. Here are a few things I learned the hard way.
A Little Background
In case you haven’t read Mr. Larson’s article yet, the concept of passwordless login is fairly straight-forward:
- You enter your email address.
- A one-time use, random code is generated, appended to a link, and emailed to you.
- You click the link in the email.
- Website verifies the random code in the link and logs you in.
That’s it! You’re logged in without being prompted for a password. As icing on the cake, most sites already have a similar “forgot/reset password” workflow, so the development cost is minimal. It’s a no-brainer, right? Not so fast.
Simply Out of Control
You’ll leverage your current password reset function and start sending passwordless login emails in no time. But here’s the part you may not have considered fully: once a login email is sent, the process of your user logging in is now totally out of your control. I had a mini panic attack just writing that. Time to deal with the unknown.
First and foremost, you have to make sure your login emails get delivered–you’re whole login system hinges on it! While email deliverability may not be a concept you’re familiar with, you want to get familiar with it before you roll out passwordless login. Basically, email deliverability is the likelihood that an email you send is accepted by the recipient (not flagged as spam). For a crash course, Google it. You’ll be met with a few truly terrifying headlines: 19 Email Deliverability Terms Every Marketer Should Know, 9 things that are killing your email deliverability, etc. Hold up–I thought I was simplifying my login process!
SOLUTION: There are a number of reputable transactional email services that will reliably deliver your email. Do your research and be prepared to pay–how will your customers login if they can’t receive your emails? You need a reliable, reputable email sending solution. Follow the provided guidance regarding DNS records, like SPF and DKIM. Also, it’s probably wise to send login emails from a different email address than your marketing emails.
Email deliverability is complicated because your new login system is actually setup to send spam … no, seriously. Anyone can enter any email address, and you will send an email to that address. It could be an innocent typo or it could be someone with too much time on his hands. Either way, you will send email to people who didn’t ask you to.
In addition, we all hate spam and often go too far to prevent spam from hitting our inboxes. Have you heard of a challenge-response spam filter? You will when you start sending login emails. To prevent spam, users (read: government agencies and dinosaur corporations) have their email system automatically reply to emails from unknown senders with a challenge the sender must complete before the message will be delivered. I doubt you were planning on monitoring and responding to more email as part of your new, streamlined login process. Actually, you’re probably sending login emails from a “noreply” address that isn’t monitored. What are your overzealous spam-fighters to do now?
SOLUTION: At a minimum, make sure your login email clearly explains why it was sent and give recipients simple outlets to report abuse and/or unsubscribe instead of reporting your email as spam. Ideally, you’ll also want to throttle login requests by IP address and email.
Also, provide easily accessible guidance for users to make sure they receive your login emails without having to contact you. Tell users to add the email address you send login emails from to their contact list–spam filters are much more likely to let email from known contacts through.
As if spam filters aren’t enough, your emails will run through virus scanners as well. This one should be a non-issue, but our emails have actually been flagged by virus scanners. Sometimes the entire email is quarantined, others the “login now” button is removed. This is very rare and I’ve only seen it in emails sent to large companies, but it happens and you, like me, probably didn’t think about it beforehand.
SOLUTION: Provide a text link for the user to copy/paste in case the image or button in the email doesn’t work.
In your effort to make your users’ lives easier, you actually introduced a few new usability issues.
A username and password can be entered seamlessly on any device–and any browser or app on that device. What if I want to login on my phone, but I don’t have access to email on my phone? Maybe I want to login with my work email address, but I only have personal email on my phone. Or what if I’m browsing your site in Safari on my iPhone, enter my email to login, jump over to the Gmail app, click the login link, and Gmail opens the link in its own in-app browser? Now I’m logged in, but where are all the items I added to my cart in Safari? Hmmm, I guess I’ll have to copy this link and paste it in Safari … only to realize the link is single-use and I already used it when I clicked in Gmail. My blood is boiling, and, as any UX designer will tell you, that’s bad for business.
SOLUTION: We allow users to navigate to a page on our site and enter their email and short alpha-numeric code from the login email. Essentially, we add “Want to login from a different device? Go to domain.com/code and enter ABCD-1234.” The short code is coupled with the link–both expire at the same time and only one or the other can be used. Also, the short code always has to be entered with the matching email address.
What’s my user name again?
While your users no longer have to remember a password, they do have to remember which email they used to login. They end up with multiple accounts – eg. one with a work email and one with a personal email–and can’t understand why the order they placed last week isn’t in their order history. Granted, users have to remember which email they used, even in a username/password system, but the difference is the login will fail with the wrong email and password combination, so a user won’t accidentally create multiple accounts.
I’ve often wondered why sites have separate signup and login forms. Why not just ask for an email and password, and either log the user in if an account exists or create an account if not? Sometimes “simplifying” isn’t the best solution. Even though both workflows require the same information, the site can provide more helpful error messages if the context of the request is known.
The issue is compounded when sites offer other passwordless login methods, like a Twitter, Facebook, or some other account.
SOLUTION: We haven’t found a good solution to this problem. Perhaps a longer-term cookie that saves which service or email address was used to login, even beyond the session cookie? As a user, I solve this problem by using a password manager (LastPass is a great option) to save the site, even when the site doesn’t require a password.
In some ways, passwordless login improves security and privacy. One of the biggest selling points is that a site doesn’t have to worry about storing and safeguarding password hashes. Users can rest assured that your company doesn’t have anything for hackers to steal, whether hashed, encrypted, or (cringe) plaintext!
However, passwordless login doesn’t remove the need for a password, just where the password is required (the user’s email provider). In the name of security, we’re abdicating responsibility for our site’s security to a third party. While users may feel more secure trusting a larger email provider with their credentials, no one is immune to hacks and data leaks. Just ask Yahoo.
Mr. Larson makes a good point though: most sites are already only as secure as the user’s email provider because the password reset feature relies solely on an email. Where this is the case, certainly a discussion about whether trusting email providers with a site’s login security is a moot point. However, we shouldn’t use one bad idea to justify another.
Don’t get me wrong–I think there is a strong argument in favor of trusting email providers with a site’s security. A significant benefit is providing users with a choice of who to trust. Maybe I’m more comfortable with Gmail, but you’re more comfortable with Apple Mail. And Fred can login using his self-hosted, private email server from an underground bunker without removing his tinfoil hat. It’s a win-win.
My point is you should consider these factors beforehand. Decide whether relying on email for your password reset function is a good idea before using it to justify passwordless logins.
In addition to the above issues, some of the outcomes of passwordless login are at odds with our goals as website and app developers.
We are in a constant battle for the attention of our users. It’s difficult (and often expensive) work getting bodies through our virtual doors. Once a user is in, we lock the door behind him and throw away the key. The life of session cookies is extending to essentially infinite, and, as I mentioned above, Gmail went as far as including a built-in web browser with its iOS app to prevent links in emails from taking users to Safari. People (myself included) are easily distracted. Jumping over to email to check for a login link can suck us into a time warp to next Monday. I may not want to buy a Santa hat for my dog next Monday.
Every website owner knows the goal is to decrease (or, better yet, eliminate) friction wherever possible. But in some ways, our efforts to simplify the login process by eliminating passwords actually creates friction. And when there is friction, the time to login increases and conversion rate decreases. Sadly, the battle for attention and minimal friction mean it’s in the company’s best interest to not only use passwords, but to allow easy passwords!
Passwords are a terrible solution to a complex problem. The password wasn’t invented with today’s computing power and today’s web and app ecosystems in mind. They’re antiquated. But, let’s be honest, so is email. Are we really pushing a technology created more than a half century ago as the revolutionary solution to our password problems?
Is passwordless login via email at least a step in the right direction? I’m not sure. We use it. But we started using it 8 years ago, and to me it’s stale. I’m ready for something better. Not a band-aid or a pass of the buck, but a well-designed, comprehensive solution to authentication and identity management.
We live in a time when incredibly complex privacy and security solutions, usually reserved for governments and large corporations, are entering the mainstream. Signal and ProtonMail make end-to-end encrypted messaging as easy as their alternatives. Certainly, there is a better, more secure solution to this complex security challenge. Maybe Jim Clark (Netscape co-founder) is right, and the solution has been right under our nose for decades: TLS, or public-key cryptography.
Until a better solution comes along, make the best of an unfortunate situation by grabbing a password manager (LastPass, 1Password, Dashlane) as a user and considering the challenges before jumping on the bandwagon of passwordless login as a company.