0

I want to have users log in by entering an email, and then proving that they control that email. I only care that they do control the email, and so want to avoid add another password to the process if I can safely defer to the security guarding access of an email sent to that email account (to cut out a class of attack, I don't care about fundamentally trustworthy parties who can access the email legitimately, such as IT people at an organisation).

I've given it some thought and have come up with the following scheme. There are a lot of answers on here that give me pieces of information about the parts, but I was wondering if this specific scheme, in its entirety, is enough for me not to have to use my own password system on top of an email verification system, to avoid illegitimate third parties logging in under an email address they aren't supposed to be able to access.

  1. submit the email address john@example.com
  2. generate a random token e.g. 'first-token' (just pretend that's random!), with an expiry of say 2 minutes (configurable, just some shortish length of time)
  3. send an email to john@example.com, containing a link to fire a GET over https to a login endpoint with the email address and 'first-token' as query params
  4. the first time the login endpoint is hit with 'first-token' and 'john@example.com' whilst 'first-token' is still not expired, another token 'second-token' is generated and sent back. 'second-token' then becomes the longer-lasting access token for john@example.com, with some longer expiry (days, perhaps)
  5. if the login endpoint is hit with 'first-token' and 'john@example.com' after 'first-token' is expired, an error is returned

So, assuming the user has their email account secured with a password that's hard to crack/socially engineer out and all the rest - how secure is this login scheme?

My immediate thought is that, as I've heard email is unsafe and can be intercepted as plaintext on the wire, this isn't secure at all. However I don't understand very well how big a problem this is - can emails sent to an account be targeted for interception without knowing the specific servers the email will pass through? How likely or even feasible is it for a specific email to be targeted, intercepted and read if you're not, for example, part of the organisation whose email server will eventually receive the email?

And, if it is unsafe, then doesn't that effectively mean most 'forgot password? I'll send you a rest link via email' flows on the internet are vulnerable to attack, as they all use something very similar, or even weaker, than the scheme above. I'm just talking about making this back door the front door - but either way the door's going to exist, right? Which leads me to believe that this scheme could be considered secure in practice?

I've thought about potential security holes in this scheme as far as my knowledge on the subject will allow - I'd really appreciate some help from the experts!

  • 3
    If you don't want to roll your own password authentication, then why not consider using OpenID? Going by your design, anyone who needs to log in to your site would need to go through a cumbersome process similar to "forgot password". Each time they do this increases the likelihood of their account being hijacked. How often do you forget your password? – Question Overflow Sep 18 '14 at 1:49
  • @QuestionOverflow I guess the goals are to verify the user controls the email they log in with, and authenticate, all in one. I think there are holes in the experience that I haven't thought through, and maybe the solution is to just use the more standard password (perhaps using OpenId, or my own private password system), and one time email verification scheme. I'm really just experimenting here, trying to figure out security holes that could make this proposed 'login via email' scheme a really bad idea. – davnicwil Sep 18 '14 at 16:41
  • POP3 and SMTP can be secured using TLS as it is done with HTTP. check my answer here security.stackexchange.com/a/191874/21144 – elsadek Jan 4 at 18:00
  • Nearly all public services are based on the security of the email flow. No matter if this is used for signup, reset or login links. This has very low actual protection and even lower assurance, but it’s still good enough to base a fortune on it. So it all depends :) – eckes May 4 at 18:37
  • @eckes It may be the weak link in authentication, but it's not the only security feature when it comes to business. Insurance protects a fortune even if authentication is broken. Deterrence is a security measure. (The more money at stake, the more serious police will take the theft.) And theft itself may potentially be limited by placing limits one how quickly funds can be transferred. (Or, in another business, rejecting orders for 1000 pizzas delivered to one home address.) – Future Security May 4 at 19:36
0

A similar question was posted recently: Is this password-less auth flow secure?

My answer - in short - was, don't do it (creating a new "security protocols" requires a lot of knowledge, effort and QA and apart from that the combination of mail, get-parameters and so on sounds pretty error-prone).

To the question "how secure is mail":

The problem is, both sending mails (via smtp) and receiving mails (via pop3) are unencrypted. It's exactly the same thing as using http for web traffic: a man in the middle (mitm) can read and compromise everything.

The question is, how big is the risk of being a victim of an mitm-attack? This depends heavily on the scenario. Are you often connected to a public wifi? Then chances are good that there might be a hacker or just a troll in the network. Are you mostly connected to a switched and properly configured private lan? In this case, it's harder for an attacker to compromise the network and sniff the traffic. How responsible is your internet behaviour in generall in terms of "accidentally" download a malware? And so on

-2

Login via email can be done safely as you describe above if the website is set to use SSL/TLS. Email itself is send unsecure (readable) over the network and might get intercepted. However, if the attacker doesn't have the first token it is useless to only have the second key that is send via email.

The downside is the fact that you can only login once as the first token that you set must be (very) time limited. The longer the time frame is set, the more time is allowed to brute force the authentication.

Also consider that some security measures might be in place that will delay email delivery for up to 15 minutes. This will be very annoying for your users to go through each time they want to login.

  • The hacker can request their own first token. The web browser is unauthenticated at that point, after all. So it isn't possible to ensure that only legitimate users receive the first token. – Future Security May 4 at 19:43
  • The attacker has the first token if she initiated the login (if there is actually one: typically in a reset link scenario there is no binding to a browser session) – eckes May 4 at 21:12
  • Bruteforce attacks against random tokens isn't a concern, and that isn't why you would want a token to expire. Bruteforcing a sufficiently long and random token over the network is completely infeasible. – meagar Jun 12 at 0:06

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.