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?

  • 2
    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
    Commented Mar 17, 2014 at 17:36
  • 2
    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
    Commented Mar 17, 2014 at 17:41
  • 3
    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". Commented Oct 6, 2016 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. Commented Oct 6, 2016 at 3:02

3 Answers 3


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! Commented Mar 23, 2014 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.
    Commented Sep 13, 2017 at 19:21
  • 3
    Security questions are just plaintext passwords that you can grep for, at this point. Commented Nov 10, 2017 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
    Commented Nov 13, 2017 at 11:37
  • 2
    What's the problem with security question? My first per name is 7GxGgJ5tHNA4A-glwwadxfDq_-wtLKsTyYlOa
    – Max
    Commented Jun 19, 2020 at 20:05

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.

  • I know this is an old question, but what happens when your email account gets hacked? Does the attacker automatically gain access to the system in question assuming they don’t use security questions or some type of 2FA? Certain fast food apps are now using this approach without any other 2FA, and you associate a credit card with your account to order food with the app. I’m struggling to see how this is different from them doing traditional password login but forcing you to use the same password as you used for your email account at all times?
    – bob
    Commented Aug 19, 2022 at 12:03
  • If I’m correct in my assessment, this feels like a major step back security-wise?
    – bob
    Commented Aug 19, 2022 at 12:04

Answering the question 6 years after it was asked, there should be some changes in the actual situation, hopefully marketing has not gained control over the new system since 2014. Hope the answer is still relevant.

If your system rely on the access control of some email system, it is basically depending on a username/password combination.

So far, it is much alike other OTP systems, and with a 2 week window, which may be rather long for most systems, and definitely too long if the token is granted for security reasons, it does not give more advantages than those.

By the way, it is not a 2FA, even the email is the second system you check for security reasons, it will depend on a password, and if you insert some "security questions", the system will be still relying on "something you know", which is still a 1st factor. You get a 2nd factor if you introduce "something you have", or "something you hold", if you will.

For the situation in 2020, you have fundamentally the same security as in most "password recovery by email" implementations.

About the second question, it is hard to prove a negative, more now that have been 6 years since.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .