I was resetting my password on a website and the website emailed me a new password in plain text rather than giving me a reset link to change the password myself. I logged back in and changed the password to something else.

I'm wondering - Does this email indicates that these passwords are stored in plain text or with reversible encryption?

The difference between this and other password reset questions (which may or may not be technically significant) is that I could decide to keep using the password they sent me and not change it.

  • This differs from other password plaintext questions because it asks about password resets not about the emailing of initially created passwords that should be hashed and not stored.
    – Fernando
    Aug 16 '15 at 17:50
  • The ability to still use the password afterwards, while significant is not necessarily relevant to your question. Whether or not they store the password as plaintext is not related to the fact that they do not automatically make you choose a new password upon the next login.
    – Anonymous
    Aug 16 '15 at 18:20
  • My humble observation is that the answers on "original" questions Are not always adequate, and asking "the same" question again can often produce fruitful results. Although I am not necessarily strongly asserting that to be the case in this instance. ;-) Aug 16 '15 at 18:57
  • you might want to notice the PlainTextOffenders - Crew: plaintextoffenders.com Aug 17 '15 at 5:13

No, this does not indicate whether they are storing your password in plain text or with reversible encryption. They might be, but this still leaves other possibilities open. All you know for certain is that they created a new password and emailed that new password to you. That password may well be hashed appropriately for storage in their system.

However; this is a poor security practice and I would absolutely gripe to them about it, and point out that such a poor practice in one regard makes you suspicious of the quality of their security practices in other regards.

Email is not secure, and they shouldn't be doing password resets by sending you a new password in any form, anyway.


I just installed an open source file transfer application on one of our servers to check it out.

I confirmed that it is hashing passwords for storage in the database, which increased my comfort level. Then I created a couple of accounts and realized that the stoopid thing emails the passwords at the moment of account creation in plaintext to the new account holder.

I am beside myself. One of these was actually a fairly sensitive account, for which the account holder should absolutely not have to change the password (but will now be forced to do).

This utterly stupid, utterly non-secure nonsense has got to stop. A plaintext password should simply never, ever, under any circumstances EVER be emailed. Ever. End of discussion. That entire mode of thinking should be quashed instantly whenever it is encountered, and public websites that engage is such practices should be punished for it.


They should be doing password resets by sending you something like a reset link with a (long, complex) embedded code/token, which permits you to choose your own new password, over a secure (HTTPS) connection. Ideally, upon clicking that link, you would still be required to answer another security question or two, in order to confirm your identity. Or some kind of 2FA should be implemented, where you click the link, then you have to punch in a code that was texted to your phone. And I still feel that you should have to answer at least one more security question on top of that, because 2FA is still utterly susceptible to having your phone stolen or cloned.

That reset link should have a very short valid lifetime. In my opinion, it shouldn't work for more than about 5 to 15 minutes. If you don't get around to changing your password in that time frame, you can always request a new link when you're ready.

If you ever encounter a site or service that sends you your existing password in plaintext, then you must assume they're storing it in plaintext or using reversible encryption.

  • 2
    "they shouldn't be doing password resets by sending you a new password in any form, anyway. They should be doing password resets by sending you something like a reset link with a (long, complex) embedded id" How would sending a link be better than setting the complex id as the password and sending that as a one-time login password that requires immediate reset upon login?
    – Anonymous
    Aug 16 '15 at 18:25
  • 1
    @Anonymous I answered that in my post (additional security questions, 2FA, extremely short reset token lifetime). Aug 16 '15 at 18:31
  • A bit off topic I think. The first paragraph does not add anything that was not included in the other answer, while the others (while informative) do not answer op's question and are not related. Aug 16 '15 at 18:35
  • @user1301428 ?? You mean the first answer to this post, which presumed the website in question was passing the current password in plaintext, when the OP said the website was passing the new password as plaintext? This answer was being typed at the same time as the "first" answer, incidentally, and was posted after that one because it is somewhat longer and more descriptive...thus taking longer to type. ;-) Aug 16 '15 at 18:37
  • @Craig lol this is not a challenge. I was merely pointing out that explaining how to implement password resets properly or how to harden the process does not answer the question of whether receiving the password in plain text means that this password is also stored in plain text. Aug 16 '15 at 18:42

Not necessarily, I don't see an immediate correlation between the two.

What is probably happening is that the application got your plain text password from the POST request and sent it to you as a reminder. It is likely that they are not retaining the plain text version and that they are keeping its hash instead.

If, on the other hand, you haven't typed the new password yourself, but was generated by the application instead, nothing is stopping the developers from generating a password, sending it to the user and then hashing it and storing it in hashed form.

However, it could also be as you said (even though I find it unlikely), but if you want to be 100% sure, this is one of those questions better addressed to the developers themselves (supposing they would be willing to share this type of information with you, of course).

  • 1
    The OP said they sent the new password as plaintext, not that they sent the old/existing password as plaintext. If the latter were true, I would absolutely presume they were storing the password as plaintext (or reversibly encrypted). Aug 16 '15 at 18:16
  • @Craig You could still do that by fetching the password as it is being input and as it ends up in the $_POST array (or equivalent), before hashing it. So both things can be really, but this fact does not automatically imply that they are also storing the password in plain text. Aug 16 '15 at 18:32
  • 1
    That would seem to imply that the user knew their password and were able to type it, thus having it end up in the POST data. In which case they wouldn't need to use the reset function. Otherwise, the password would have to have been retrieved from persistent storage, where one would have to presume it is being stored as plaintext or reversibly encrypted. Aug 16 '15 at 18:35
  • @Craig Ok, in this case nothing is stopping you from generating a password, sending it to the user and then hashing it and storing it in hashed form. In both cases, I think this should be addressed to the developers as there is no way we can answer it ourselves. Aug 16 '15 at 18:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.