1

(Please read the update at the end)

I am trying to find out how to send user registration emails securely. I read answers on this question:

I don't intend to send passwords in emails, but I was considering something similar to this answer (temporary links).

However, I keep asking myself the same question someone asked in comments to that answer: "So what's stopping the link in the email from being hijacked by a middle-man who uses the link to reset the user's password?"

UPDATE: Sorry, I wrote this in a haste (I need something done "yesterday"). I am basically concerned with email hijacking in general. What actually happens is this:

  • Someone creates a Tenant (an organization) account. This is standard registration and I am doing it with a temporary link that is sent to the user.
  • Admin user is created in the first step.
  • Admin user later creates other accounts. This part is where I am concerned about email hijacking.

I could send a temporary password to the new user. I also considered 'invitation' email, where the new user would get a temporary link where they could insert their password (the link would be deleted after that).

I am not happy with either solution, because I feel like someone could hijack the email and either read the temporary password or use the temporary link to insert their own password before the user does.

I hope this makes my question more clear. If not, please tell me and I'll try to improve it.

Community
  • 1
Viet Norm
  • 13
  • 3

2 Answers2

2

I'm going to take this question as to "how do you stop MitMs from intercepting temporary links" whether those links are for email confirmations or to initiate password resets, because email is considered insecure.

Well the answer is around the fact that not all Men-In-The-Middle are created equal.

It might well be the fact that the email in transport is sent unencrypted (although nowadays opportunistic encryption is utilised), however the point in its journey that is most risky for occurances Men-In-The-Middle is usually encrypted.

e.g.

server --> Local SMTP server --> User's SMTP Server --> User

The most likely scenario for a MitM to sit is between the User's SMTP Server and the User. However, these days encryption is more or less universal for this link. For example, if you get your email via Gmail or Outlook (Hotmail), you connect to your provider via HTTPS, meaning that any MitM on the unsecure coffee shop network you retrieve your email from is protected. Same with Outlook connecting to Exchange Online, as the connection is encrypted. Protection here is most critical as all it takes is one rogue user with ARP spoof in order to intercept all traffic.

A MitM placing themselves at other points in the delivery chain is much harder, therefore it is an acceptable risk for most sites to send out temporary, single-use tokens via email.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • That's pretty much what I wanted to ask, thanks. I guess hijacking an email isn't as easy as I thought. – Viet Norm Apr 07 '16 at 13:42
1

Registration Email Confirmation

So what's stopping the link in the email from being hijacked by a middle-man who uses the link to reset the user's password?

That's not how your registration email should work. It should work like this:

  1. User registers
  2. You send out a confirmation email with a one-time token
  3. The user gets the email and clicks the link with the token
  4. You compare the token and if it matches, you mark the email as correct and remove the token

The idea here is to validate the users email address. The user should not be able to do anything other than confirming their email address with this token. They should not be automatically logged in, and they should not be able to reset a password.

Password Reset Token

Here the described problem exists, and there is no good solution (email encryption is not used enough to be a proper solution).

What you need to do is make sure that the token is one-time only to somewhat mitigate damage.

Other than that, you could use two factor authentication to mitigate the problem.

tim
  • 29,018
  • 7
  • 95
  • 119
  • Thank you for the answer. That is exactly what I am doing, I just didn't bother to better explain the details (or give the question a better title :/), I apologize. So, basically, "everybody" is using email when sending reset tokens because there is nothing better / user friendly / practical, even though they know it's not secure? – Viet Norm Apr 07 '16 at 13:19
  • 1
    Another way to prevent the MitM scenario is to [insist upon the same session for the initial request and the actual reset](http://security.stackexchange.com/a/117871/8340). However, you are right, the OP appears to be asking about registration where this scenario shouldn't apply. – SilverlightFox Apr 07 '16 at 13:20
  • I edited the question to better explain my concerns, please read the updated version. – Viet Norm Apr 07 '16 at 13:37