Would You Implement Passwordless Login?

How many passwords do you use for online accounts? I have 250. That’s a conservative estimate and doesn’t include a plethora of hosting, database and SSH passwords.

Despite using management tools such as KeePass, it’s difficult to use different passwords for every site — and I certainly don’t change them as often as I should. Even then, I forget what I’ve used on specific sites. Logging in is often a matter of clicking “forgotten password”, hitting an email link, entering a new password and finally gaining access.

The average user has a couple of easily-remembered passwords for every account. There’s no guarantee every one of those sites has implemented good security measures. Perhaps passwords are stored in plain text or accessible to their staff, developers, database administrators or those working at their hosting company. Could your banking account be accessed just because you used the same credentials at dodgysite.com?

We’re using the same ID and password mechanisms we implemented at dawn of the web. But a password backlash has begun. Passwordless logins have been proposed by developers such as Justin Balthrop and implementations have arrived, e.g. passwordless.net for Node.js. The main argument: passwords are obsolete because we all have secure email and mobile SMS accounts.

Passwordless login uses the following process:

  1. The user accesses a website and enters their email address (or mobile number).
  2. A token (cookie) is sent to the device. A unique authentication code is generated and stored on the server then sent within a link to the user by email (or SMS).
  3. The user has a limited time to click that link — perhaps ten minutes. When clicked, the existing token and authentication code are verified to ensure the same user is accessing. The user is then logged on and a session is started using a long-term token.
  4. The user does not need to repeat the process unless they log out, switch browser, do not access the system for a specific duration or want to use another device.

In essence, it’s a similar process to resetting your password — which you would possibly have had to do anyway. The benefits include:

  • There’s no need for clever hardware or biometrics — the user just needs an email address or SMS number. That’s far more likely than having a Google, Twitter or Facebook account which can thwart those using OAuth providers.
  • You need never manage passwords again. There’s nothing for the user to invent, reuse, note down or reset. Support staff are freed from daily grind of account management duties.
  • The user requires a valid email to log in so the usual registration and email validation shenanigans are avoided.
  • No password is ever stored or sent. It cannot be guessed or hacked. Someone could grab your database and intercept HTTP traffic or email messages — they’d still have difficulty logging in.
  • There’s less code to deploy. Login forms have one field and security management is minimal.

Going passwordless is not a magic solution appropriate to every application. System developers will need to consider a number of issues…

User Expectations
I’m yet to use a passwordless system in the wild. While it shouldn’t be a difficult experience, few users will expect it. That could lead to additional support calls in the early days of deployment.

Logging on Takes Longer
Despite time savings in password management, passwordless login could be annoying. It’s impossible to save credentials in the browser so you can never login automatically. Often-used applications such as social networks and large online stores would avoid going passwordless.

It’s Not Suited to All Applications
Passwordless login would be difficult to implement on a webmail client! In addition, you wouldn’t want your bank handing password security to a third-party.

Email Hacking
If someone hacks your email account they have gain access to all your passwordless systems. It would fairly easy to discover which systems you’re using just by examining the deleted items folder. That said, if someone hacks your email account they can also reset your password at many sites using standard authentication.

However, a large number of applications could benefit from a passwordless approach. You could certainly consider it if your system is used fairly infrequently and has minimal security implications, e.g. forums, support ticketing, analytics, monitoring, reporting systems etc.

Passwordless isn’t for everyone. Implementation libraries are scarce and some companies would be nervous about becoming an early adopter. But I like the idea and investigating the viability for a system I’m working on. I’ll let you know how it turns out.

Would you go passwordless?


Makes a lot of sense Craig. As you say, it is no more vulnerable than most (nearly all?) login/password sites as they utilize email for forgotten passwords. I am a big fan of passwordless (when appropriate) - and implemented it in a different fashion for 2 of our casual sites: LooseLeaves and DoitDoitDone. Here we just generate a unique access URL for each item. Its very low security, but also very convenient and anonymous.


Really? Why?

I like it. :) I may offer this as an option to users on the next site I build. You're right that it's the exact same "Forgot my password" process we already use, so why not make it the normal way to log in.


In theory, a great idea.

In practice, I could see an approach such as this being open to abuse and would require a few additional steps such as regional locking, maximum attempts per hour/day/month, etc.

The potential for crashing the service, or racking up huge SMS bills would be quite high, and similar risks with email spamming. (A malicious person/group abusing the login page)


Steve Gibson's SQRL idea is perhaps a much better system to relive the "annoying" part of logging in this way.


I would not want passwordless login in the way mentioned in this article. Using LastPass is plenty easy and I can use it on all my own systems, or log in to their website to retrieve passwords if on some other system.


That's a good point. It's also a problem that neither email nor SMS is encrypted during transit. It would take a sophisticated hacker to exploit that, but the possibility is still there. But then again, we already do this anyway -- even banking sites -- with "Forgot my password".


I agree with @zackw. SQRL is the only one I'd rely on because it's the only one I've seen not dependent on a 3rd party. I hope it takes off in a big way. For now, I'll keep using 1Password to generate long, very random passwords unique to every site.


Really? Why?

Because opening KeePass (or similar) is still more difficult than using the same password on every site!


I'm not sure you would need as many security checks as standard password systems. The token link you're sent will work only once and must be associated with the existing token you have in your browser. Even if someone obtained the link, they wouldn't be able to use it.

As for risks of email spamming, remember that an email could only be sent to a registered user so it wouldn't necessarily be prone to attacks. Limiting requests would be an option, though.

SMS costs could be high, but it really depends. Some services are free and it could be negligible for a small number of users. That said, I think email would be more practical in most cases.


For this reason alone I would probably implement this into personal websites (don't want to try pitching this to any clients...)

I just bank on the fact that google (gmail) has better security than I could give - thus I'll let them safeguard my token smile .

Pretty smart idea - good article!


SQRL looks interesting although you are (mostly) depending on a mobile phone with QR scanning. That may not always be an option and I'm not convinced it'd be less hassle. Nice idea though.


I think I agree with @Jeff_Mott here

Despite using management tools such as KeePass, it’s difficult to use different passwords for every site

It's not really difficult if they're used well... I feel the same way about password managers as I do about task managers. If you don't entirely trust and depend on your system, it'll end up just being a burden.

On the other hand this sounds like an interesting idea to try out.

And @RyanReese

For this reason alone I would probably implement this into personal websites (don't want to try pitching this to any clients...)

I just bank on the fact that google (gmail) has better security than I could give - thus I'll let them safeguard my token smile .

That makes sense to me too... perhaps if more developers began using it in our own projects or in more tech-friendly communities, then the problems in this kind of system would be naturally worked out before we started pitching it to clients? And yes... regardless of the Google Evil, I trust them... way more than I trust me, to be able to safeguard my stuff. They're just clearly more capable.


I just have a hard time believing clients would like to be the "test run"...they don't see any other sites doing passwordless logins so why would they want to be the first? And for that matter, you are the developer - they don't want users navigating away from their website to login. They might find that as a nuisance compared to just giving a password (plus, you are expected to be able to give them code-security...if you can't, then there are others out there!)


Actually, SQRL also has a sqrl:// protocol handler so you can click or touch it to launch an app for authentication without using a camera to scan the QR code.


You wouldn't be the first but, I admit, clients may not appreciate the benefits because they haven't seen it. And, as I discussed, there are sites where it would be impractical. However, those sites you log into infrequently could be ideal - whether that's because it's a tool you don't use often or the session can last a long time (e.g. a social network).


I'd go password-less until they got really serious information. But for most of the things that I use, a password is really not needed.
I use LastPass to keep all of my passwords, but even so, it's a pain logging in on all the different devices I have. Nobody handles the mobile thing well (I have LastPass premium and it works, but not as well as the desktop version).


Sorry, but I think its a retarded system...Why would you log into your e-mail to log into a site or system?

Go to site......
Now go to your E-mail
log in....
find E-mail
Go back to site....

Why would I ever want that processes. It'd bad enough having to do when you forget or if it gets compromised.

It would also makes things less secure.. instead of having 2-3-4 passwords people would only actually have 1!!!

Hack one e-mail account and have access to x amount of accounts!!!!

Its absurd!!


If your email is hacked, all your online accounts are compromised. The hacker can go to any website and click the "forgotten password" link. Passwordless login is no more or less dangerous.

Admittedly, passwordless login is more cumbersome but you're not quite describing it correctly. For most people, it would be:

  1. Go to site
  2. Enter email address.
  3. Switch to email app (most will already be logged in)
  4. Click link in first email message.

It's no more awkward than using a password manager with the additional benefit that you don't have a password to forget. But I certainly wouldn't recommend it for a system which has short session expiry times.


The "secure email and SMS" part made me laugh. There's very little secure about either.


What's not secure about that?

Gmail isn't secure? You are saying that you can create a more secure login than Gmails security? Impressive.


Let's start with SMS: http://www.washingtonpost.com/blogs/the-switch/wp/2014/12/18/german-researchers-discover-a-flaw-that-could-let-anyone-listen-to-your-cell-calls-and-read-your-texts/

Email suffers from other problems. There is very little security built into the email protocols, and there's a bunch of issues with HTTPS being discovered recently.

Can I create a more secure login system than Gmail? Easily. Note, though, that that is only part of the problem.

Here is what you do:
1. Generate a key pair for public key cryptography. You can do this in JS in the browser these days.
2. Send the public key to your server along with whatever user identifying information you want.
3. Have the server sign it if it is happy with the user information, and send it back signed.
4. Install the private key part and the signed public key as a client certificate and use that for authentication from now on.

Is this convenient? With some effort, it could be made to work. Mostly, though, there are some lessons to be learned from it:

  1. Password based authentication is insecure, get over it.
  2. Replacing it with less security (as proposed) is a terrible idea, unless you work for the NSA. A more secure future requires more key management, not less. The key is to drive browser adoption of good key management solutions. Good key management makes using unique site keys easier, too.
  3. This is still a bad solution; get used to the idea that SSL/TLS is a stopgap solution for security. We need more end-to-end security, and less transport security. But that leads off into an entirely new direction.

Back in the day when I was writing CMS for a few clients I always used this idea. Most of the people I was coding for were were using the CMS from work where they were already on their email. It made sense because it was easy (enter your email address and click on the link when it arrives) and you know when someone else is trying to enter the system using your email.


Therefore, any system which allows you to reset password or - worse - have it emailed to you is inherently insecure. Passwordless login is no more or less dangerous. Of course, it doesn't need to be email or SMS - it's just that those are the two most likely systems people use.


You're right. They are insecure.

Read my argument again. I'm not suggesting passwordless login is less secure than password based (though I haven't really tried to analyze it; it might well turn out that it there is a significant flaw). I just commented that "email security" makes me laugh.