18

I'm proposing the use of a login system that sends a one-time login token (with high entropy) via email to the user. After using the token, the user receives another token via email and the previous token is invalidated. The new token is sent with information about the use of the last token, so if someone does gain access to a token somehow the user will know.

The implementation I have has received great feedback as far as UX goes, but I'm facing a lot of pressure from non-techs to "prove" that this is secure. Additionally, our marketing team is concerned that this will be hard to teach customers about.

Aside from the lifetime of the one-time login tokens (they can last a couple of weeks), what makes this any different than forgotten password functionality? Additionally - and this is where this question isn't as easily answered as others that are relatively similar here - 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?

  • 1
    Your idea does have some security benefit over email+password with self-service password reset. For example, the user cannot use the same password with other accounts, and cannot choose a weak password. Consider timing out the login links instead of cancelling them after use. If someone attempts to use an expired link, you can simply email them a fresh one (and tell them you have done so). – Ben Mar 17 '14 at 17:36
  • 1
    In my view this is a suitable system for low value logins which are used infrequently. Essentially anywhere that an emailed password reset link (with no further authentication) would be acceptable, this should also be acceptable. If the user uses the system less than once per month they are unlikely to both a) choose a secure password AND b) remember it without aid, so your system is actually better, especially if you are prompting them to log in by email anyway. – Ben Mar 17 '14 at 17:41
  • 2
    It is no more secure than "forgotten password functionality" but it is arguably more secure than having two authentication mechanisms: a "traditional username/password" as well as "forgotten password functionality". – joeytwiddle Oct 6 '16 at 3:00
  • 1
    This article notes some important restrictions: the email token can only be used on the device that requested it, and it only lasts 10 minutes. – joeytwiddle Oct 6 '16 at 3:02
  • What’s the purpose of sending two tokens rather than one? – user76284 Aug 2 at 5:36
9

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, the one-time limit a) prevents the untimely release of the token (even by search engines and indexers) from becoming too much an issue, and b) provides visible notice to the user when their account is being used. Thanks for confirming! – James Kassemi Mar 23 '14 at 19:45
  • 1
    btw @JamesKassemi and paj28, those security questions only provide a tiny additional amount of security... mainly a deterrent to less-determined crooks. Any determined crook with access to big data algorithms can often find the name of your first pet on Facebook with hardly any trouble. Thus, security questions provide a false sense of security and are deprecated in the latest NIST standard. – NH. Sep 13 '17 at 19:21
  • Security questions are just plaintext passwords that you can grep for, at this point. – Adonalsium Nov 10 '17 at 17:36
  • @Fistbeard - Maybe. I think they add some security at least. Thought experiment: what is the make of my first car? my favorite colour? name of my first pet? – paj28 Nov 13 '17 at 11:37
  • To get that information I'd most likely try to find people who are mutual friends with you in the Facebook groups you're a member of, then I'd make up some story to ask them. Perhaps I'd say I was a friend looking to put together a collage from when we were friends a while ago, and was trying to sort through my parent's old photo album. Won't they help jog my memory by sharing the name of your cat, or remind me what your old car was like? Oh and don't tell Paul, it's a surprise. More to the point- While you and I are savvy enough to not use questions that can be found directly, most aren't. – Adonalsium Nov 13 '17 at 15:16
7

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...

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.