Passwordless login over email - security considerations

You are correct that the security of your system is similar to that of most password reset systems. It is as secure as the email addresss - no more and no less. Be aware that some password reset processes ask additional questions (e.g. what's the name of your first pet?) which do provide some additional security.

You will have a hard time persuading a non-tech of the security of this. One approach would be to do a Threat Model of your system and show this to them. I doubt they would read it though. The thing is, computer security is far from perfect, so you really have to think about what happens if it goes wrong. If you have a breach, it may seem much harder to justify your non-standard system. There's a lot of be said for doing the same as others.

I have seen live systems that take your approach, including Doodle and RT. Some surveys also do it.

I'm curious why you reset the token after it's been used. What was your thinking?

One threat to be aware of is browser search bars. If a user has these installed, all the websites they visit may get sent to the search engine. This could end up with http://yoursite/token/ being added to Google's index, which is clearly not desirable. Your approach of one-use tokens actually prevents this. Another approach is to always use "no index" meta tags or robots.txt.

What you have created here is what I'd call "poor man's single sign-on". You may be aware that there are some standards for web single sign-on, including OpenID, OAuth, Mozilla Persona, and more. However, none of these has gained a critical mass.

Yes, I'm fascinated by this as a possible passwordless authentication mechanism. And as you & others have already mentioned, it does offer the same security as most forgot-your-password systems ...although the better ones do require you to answer some kind of security question also, making it more like two-factor.

Anyway, the now defunct site Passwordless.org offered a good outline...

Here’s how passwordless authentication works in more detail:

1. Instead of asking users for a password when they try to log in to your app or website, just ask them for their username (or email or mobile phone number).
2. Create a temporary authorization code on the backend server and store it in your database.
3. Send the user an email or SMS with a link that contains the code.
4. The user clicks the link which opens your app or website and sends the authorization code to your server.
5. On your backend server, verify that the code is valid and exchange it for a long-lived token, which is stored in your database and sent back to be stored on the client device as well.
6. The user is now logged in, and doesn’t have to repeat this process again until their token expires or they want to authenticate on a new device.

If every site on the internet did authentication this way, the response to Heartbleed could have been swift and decisive. Instead, we’re faced with the fact that millions of stolen passwords will never be changed.

Are there any respected companies who have implemented a login scheme like this, and are there any papers you can recommend I point to to prove the security of this system?

I know Medium.com gained a bit of press recently for only requiring an email address for authentication. Some articles...

• https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd
• http://venturebeat.com/2015/06/29/medium-doesnt-think-it-needs-passwords-to-offer-secure-authentication/
• http://www.interworx.com/community/mediums-email-login-sidesteps-password-problem/

And Yahoo do a similar thing by providing one-time passwords via SMS:

• http://www.pcworld.com/article/2897332/yahoos-new-ondemand-password-system-is-no-replacement-for-twofactor-authentication.html

As for research papers, I'm not sure yet, but I would love to hear of some.