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!

davnicwil
  • 1,231
  • 2
  • 8
  • 8
  • 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 01: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 https://security.stackexchange.com/a/191874/21144 – elsadek Jan 04 '19 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 04 '19 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 04 '19 at 19:36
  • If you want passwordless login, you should use an established protocol like OpenID Connect, which uses encryption for every step, rather than rolling your own login flows which rely on receiving an email. – user229044 Jun 12 '19 at 00:07
  • @meager this was about proving access and control of an email account, any email account. OpenID wouldn't solve this problem because the email account provider would have to support it - this needs to work with any email. Agree it's a good general solution if avoiding creating yet another password is the goal, though. – davnicwil Jun 12 '19 at 01:52

2 Answers2

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

Alex
  • 273
  • 1
  • 2
  • 7
-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.

Dirk Krijgsman
  • 97
  • 2
  • 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 04 '19 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 04 '19 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. – user229044 Jun 12 '19 at 00:06