I found myself telling a coworker today "Email is insecure, that's why we developed our secure report application."

But then it struck me, Why is email considered insecure? If it is so insecure, why do we trust it for password resets?

I never questioned it before...

  • 7
    Good question. The inherent insecurity of email is the reason that best practices dictate that password reset mechanisms should generate passwords that are valid only for a limited time, why passwords and usernames should never be sent in the same email, etc. A whole lot of care has come about because we just don't have anything better. Commented Jan 22, 2013 at 20:40
  • @John - Unencrypted email is not secure. There are ways to make email secure the problem is that most software was not designed to support encrypted email. There is also the fact that at the end of the day, only the contents of the email would be secure, the same attacks that make email insecure could be used against encrypted email ( in theory ). Of course one could argue that email is the most secure thing about the password reset process just ask Playstation Network admins ( people were able to guess what the confirmation link would be ).
    – Ramhound
    Commented Jan 23, 2013 at 12:50

4 Answers 4


We trust email for password resets because we do not have anything better. It is not really a matter of trust as in "we have full faith in the email"; it is more like "eh, as if we had a choice...".

In particular with Web-based business with consumers: a consumer is authenticated by his dynamic IP address (cannot be used except as part of a police operation with warrants to uncover the ISP logs), possible credit card details (idem), and whatever the customer accepted to tell us, which, at best, is a valid email address. So, email.

  • 1
    Gotcha, wow... Kinda sad, isn't it? Could you add something to your answer about why email is considered insecure in the first place?
    – John
    Commented Jan 22, 2013 at 21:01
  • 2
    @John: see this answer. Also, most of it can be transferred as plaintext, unencrypted (it depends on what the relevant servers decide to do, there is no guarantee). Commented Jan 22, 2013 at 21:09
  • 1
    Any other means I've seen used is even less secure. So basically, you use what you've got. Commented Jan 22, 2013 at 21:11
  • 7
    Actually we do have something better. If you send us your current location, we can send someone out to authenticate you based on examination of your drivers license, passport, social security card, etc and then give you a new passport. Most (if not all) web based business have decided based on a cost-benefit analysis to use email, but it is conceivable that it is justified for some business.
    – emory
    Commented Jan 23, 2013 at 1:08
  • 5
    @emory: if we can support the cost of sending someone to authenticate the user, we may as well give him a hardware token (OTP generator, smart card...) instead of using passwords. No password, no password reset. Commented Jan 23, 2013 at 11:18

As you know, a link which you open in your browser is not tunneled to an endpoint. So its open to many attacks. However, that is why there are other verification methods build in. As an example, many systems offer 2 or 3 factor authentication methods. It involves implementation/deployment/maintenance costs. But, there are collaborative methods:

  1. Mobile verification codes (note that sms is not a secure method however).
  2. Verify yourself with something you know (and something you have can be assumed as the link you got), like your answer to a secret questoion or a pin number etc. Note that the next page is secured by ssl/tls most of the time. Even a security card (smart cards etc) can be integrated or used to recover passwords with or without the email address (used by some companies but, with in house developed/installed systems - additional security mechanisms)
  3. Integrated with what you are can be integrated but it is avoided due to higher cost.

Much of email transit is now secure. Are there any major email service providers which don't use TLS by default? IIRC, Google doesn't even allow unencrypted IMAP access to Gmail.

I recently reset my password on Yahoo.com, and here is the header where the message was sent from Yahoo's network to Google's:

Received: from n2.bullet.mail.ne1.yahoo.com (n2.bullet.mail.ne1.yahoo.com. [])
    by mx.google.com with ESMTPS id pp10si18879814igb.52.2013.
    (version=TLSv1 cipher=RC4-SHA bits=128/128);

This used 128 bit encryption. Below that, the sender was authenticated by DKIM. Gmail defaults to HTTPS, so every point in transit to my browser, this email was encrypted, the sender was authenticated, etc. The message presumably went through additional automated checks to ensure that it wasn't a phishing email. This is actually a pretty secure protocol for resetting a password, all things considered. Email does not require security, but it's a bit outdated to call it inherently insecure.

  • 2
    +1 ` it's a bit outdated to call it inherently insecure.` As an email admin/engineer for 14 years, I agree. It's just complicated to secure & validate. Very few of my users know how to find the RCPT header, let alone the correct one in the list. Commented Jan 24, 2013 at 22:30

We use email as part of a password reset process because in many cases there is no good alternative. However, all password reset procedures which use email are not equal. Some are definitely better than others. As other forms of communication become more common, you will see password reset procedures move towards using these newer technologies as they are ofte more secure (or appear to be more secure) - for example, more of the systems I use now use SMS rather than email for password recovery.

Part of the reason email resets are insecure is because passwords in themselves are inherently insecure. If you augment standard passwords with something like 2-factor authentication, the risks associated with email based password resets can be reduced because the email has only part of the information required to access the resource in question.

The other point to consider when evaluating the security aspects of email being used in password resets is impact versus convenience. I really don't mind if that web site I use for tracking my grocery shopping list uses an insecure email based password reset procedure, but I do mind if my bank does (and yes, I have different passwords for each site).

Of course, there are good and bad email based password reset systems. Those which actually send you a new password are less secure than those which send a special reset link. Those which have a link which is one use only and are only valid for a limited time are better than ones that last forever or can be used multiple times. Those which are random and non-predictable are better than ones which can be derived based on some easily obtained information.

What should happen is initially we do a basic risk assessment - look at the likelihood of a password reset mechanism being compromised and the impact such a compromise would have. If the result is acceptable, the process is OK. If not, then the process needs to be modified until a satisfactory compromise is met. However, these compromises will likely be reflected in lower levels of convenience, so you need to be realistic in your assessment of both potential/likelihood of the process being exploited and the impact such an exploit would have. Over estimate either and you could end up with an over engineered and inconvenient solution. Under estimate and the process will not be sufficiently engineered to provide enough security - it will likely be very convenient and easy to use, but will expose the user to too much risk.

Bottom line, email is insecure, but if implemented well, an email based password reset process may be a good balance between secure enough and convenient. If you don't think the email based password reset facility of a service you use is sufficient, don't use the service.

You must log in to answer this question.

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