The Question

I was reading a forum last night discussing the idea of emailing a user a login link, much like a password reset link, so they don't require a password. Their email address is already verified on sign up using a similar such link and I see them as being fairly similar in principle to a reset password link.

The Process

The user would visit the site, enter their username and be emailed a login link valid for 5 minutes. They click the link in the email and they are logged in.


  • My initial concern was if an attacker had access to their email, but, they could simply use the password reset process on most sites to access the account in this situation.
  • The inconvenience to the user of having to login to their email to retrieve the link.
  • Email is not necessarily a secure medium to exchange the login link.


  • As the host you don't need to store the user's password and worry about a breach disclosing it.
  • SSO presents a single high value target for an attacker and requires implementation on your site. Does this method draw a parallel but without the dependence on the SSO service?
  • The user doesn't have to remember another password which would likely be a duplicate of a password elsewhere or very weak.


The login token would have to be both strong and random to prevent brute force attempts on it and could also contain some form of user ID to reduce the scope of an attack. Are there any other major advantages or disadvantages you could point out in the above from a security standpoint?

5 Answers 5


If you're relying on the email address to verify the original user's identity, whether for login or password reset, then a compromise of the email account means a compromise of the website's account. Therefore, I don't see any elevated security risk in this login scheme. In fact, this is essentially like using a third party authentication service. Think, logging in to StackExchange using your GMail account.

Combining this login scheme with good security practice such as using HTTPS, avoiding injection vulnerabilities, etc. can makes it on par with a password-based login scheme. The only advantage I see here is that the user will now have to remember a smaller number of passwords, that's it. The obvious disadvantage is, of course, the inconvenience of having to go to my inbox, open, the message, and click the link every time I have to login to that website.

If you're planning to use this, I highly recommend having a fallback option to allow the user to login with his password in case he doesn't have access to his email account for any reason.

  • Thanks for the response Adnan, it's quite helpful. I did think about the fall back option, but couldn't find a solution to implement it that satisfied me. If I just allow unrestricted access to it, chances are people would most likely just bypass the email token login method all the time. The next problem was that this removes the benefit of me not having to securely store their credentials. I realise this can be done easily with proper salting/hashing/stretching but no db of creds means no target for an attacker. Aug 17, 2013 at 14:42
  • @ScottHelme I'm afraid to say your assumptions are somewhat incorrect. It's very easy to securely store credentials, and if your users' password are simple enough to be quickly brute-forced from the stolen secure hashes, then they're simple enough to be brute-forced through other channels. Also, if you're being targeted by a determined individual or group, they wouldn't care if you have a credential database or not, they'd compromise you, install backdoors, and basically try to ruin you.
    – Adi
    Aug 17, 2013 at 14:51
  • I said I realise you can store them securely and I suppose I could also target the simplicity issue by having strict requirements when creating a password. From a data breach point of view though there is very limited risk to the user if I don't store their passwords, no? Yes they could ruin the web app and own the server etc... But users wouldn't be at any greater amount of risk. At least, that's my thinking :-) Aug 17, 2013 at 14:57

A user might want to visit your website from a computer where they have no access to their e-mail account or do not want to access it. Your process would limit the computers where the user can access your site.

  • 1
    You make 2 good points that I'd like to expand on. Would the lack of access to email really only be somewhere where there was no internet? If so then the login to the site isn't possible anyway. Then, if they wouldn't like to login to their emails (security reasons?) they most likely wouldn't want to login to this site either. Are these similar points to what you were thinking? Aug 17, 2013 at 14:13
  • There may be technical reasons why I cannot access my e-mail everywhere. Take for example my corporate e-mail address: I can only access it when I am at the office or when I set up a VPN connection with a token or a client certificate. If I registered to your site while I was at the office, I can only ever access it again when I am at the office. Also some providers do not offer web-mail. That means I need to set up a pop3 account on any computer I ever want to access your site from?
    – Jeff
    Aug 17, 2013 at 14:19
  • Good point. I suppose no email access in any circumstance is a complete lock out situation. There is also the circumstance of losing access to your email permanently (host closed, account deletion etc...) to contend with. Thanks for your insight. Aug 17, 2013 at 14:22

The biggest drawback to this method security-wise is that it offers absolutely zero protection against a targeted attack on one of your users. Emails can be intercepted rather easily in a targeted attack and you have absolutely zero chance of protecting against this type of situations.

Besides the obvious security flaw, there is a huge usability concern. Requiring me to login to my email just to access your site is really annoying and will probably discourage many people from logging in.

  • 1
    Thanks for the feedback. If an attacker can easily access the user's email in a targeted attack they could simply retrieve a 'forgot password' link and access it that way. I agree with the usability concerns you raised though, that could get tedious. Aug 17, 2013 at 10:50

Sometimes users have to change their email adresses, maybe because of spam or because they changed the employer. If they are members of a lot of such websites, they have to remember all these sites and have to update the contact email. If they forget one, later they cannot login to this site anymore and therefore can't change the email address.

So i would say, there is no advantage, either you have to remember passwords, or you have to remember the sites where you must login to update the contact email. Either way it's good to have a tool like KeePass where you can store all login information safely.

Maybe there is even a disadvantage, there will be people asking for access, because they changed the email adress. Then you as administrator will face the problem whether to believe this person or not.

  • Yeah we discussed having a secondary email for recovery purposes like I have seen on some other sites. But I agree, it seems like it would be too much hard work for the user. Aug 17, 2013 at 15:14

This could be a good idea, if you required to type full credentials (username + password) first, and then send e-mail with token-link. This would work as 2-step verification (type your password, which only you are supposed to know, and then enter your e-mail, which also, only you are supposed to enter).

However, you want implement something like one-time email passwords. There are a lot of drawbacks of this idea.

Firstly, as it was mentioned above - some people have limited access to their e-mail accounts. Secondly, some people like having arrangement/tidiness in their inboxes. Removing every e-mail from your website, after successfull login, could be somehow annoying.

But these are only usability disadvantages. Let's take a closer look at your idea, from the security point of view.

What about spamming your users? If an attacker knew the username/e-mail, it could use your login-method to send tons of e-mails to your users. This situation could lead to make your customers annoyed (well, I bet, that getting a lof of messages like Click here to login isn't something they would love to get :) ). Your e-mail (this one, which you use to send messages with token-link) could be also blacklisted (due to huge traffic from it) and your other customers wouldn't be able to receive another login-emails.

OK, you could say - No spamming! I'll implement CAPTCHA and allow to send only Nth email in short period of time. Well, I'd answer - access your e-mail, CAPTCHA - what else to make your website to be difficult in use? Let's move back to the talk about usability :). Speaking of blocking requestes in short period of time - don't forget that attacker could use this method to block your genuine users and prevent them from accessing your website.

Another reason, why this idea is wrong is phishing. If your website sends a lot of e-mails, then your customers are more vulnerable to phising attacks. If some typical user, on the daily basis, clicks on the link from you domain - it's more likely, that he won't examine every e-mail from you as carefully as e-mails from his bank. Attackers could use your login-policy and send spoofed e-mails to your customers (e.g. with links to malicious content).

  • Another great answer and you have raised some new and valid points! I like the idea of the 2-step verification you mentioned initially but you are correct on the further points regarding spam/blacklist flags and DoS. Although I suppose I could limit the re-issue of the new token to the validity period of the old one, the desired short validity period would leave this open to attack. Thanks for your input. Aug 20, 2013 at 15:14

You must log in to answer this question.

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