I read this answer and found a comment insisting not to send password by email:

passwords should not be able to be retrieved by email, I hate that. It means my password is stored in plain text somewhere. it should be reset only.

This raises me the question of handling Forgot Password option?

At any cost the raw password must be displayed in any UI so that user will be able to read it. So what would be the way to handle "Forgot Password"

  • I just spent 15 minutes explaining the PHPBB forgot password feature. Oct 28, 2010 at 20:00
  • Possible duplicate of Password reset process
    – gnat
    Oct 28, 2016 at 15:35
  • 1
    @gnat Did you had a chance to check which was the oldest of the two?
    – Gopi
    Oct 31, 2016 at 4:12
  • 1
    @TechJerk age of the questions doesn't matter as explained here
    – gnat
    Oct 31, 2016 at 5:46

5 Answers 5


A good application design will not be able to explicitly recover a users password. This is because it is usually stored after it is run through some sort of hash which is a one way operation.

The best way to handle lost password is to perform a reset, email to the users account a link with a generated parameter tacked on that identifies this as a valid password reset for the account in question. At this point they can set a new password.

This does assume you have a users email address on file.

  • There are additional "best practices" that, while not critical (like not storing the passwords in the first place), should be in place if time allows, including having the temporary access token expire on certain events and over time (so that someone's account is not compromised if his inbox is).
    – Steven
    Jan 27, 2011 at 22:59

You should not store the users main password as plaintext, but you CAN store a temporary password as plaintext, i.e

user resets password -> temp password is created -> temp password is sent via email -> user is forced to change password at next log in (new password can't be temp password maybe)

  • 2
    I've done this in several sites. While you can argue that a mail snooper can get the password, they can also get whatever other temporary token etc you would email. This approach is simpler for the user (they can copy and paste or even type the temp password) and doesn't take a security hit. Oct 28, 2010 at 15:52
  • Unless somebody is using secure way to connect to mail server (i.e. web mail via HTTPS or POP3 over TLS), such communication could be easily sniffed. In that case some "haX0r" could easily log into other user's account. That's why it is bad idea. Reset link should be sent as Chris suggests and accompanied security question should be asked before actually letting user to change his/her password. Still not 100% safe (as many times answers to such security questions could be easily guessed), but I can't see any better solution. Oct 28, 2010 at 15:55
  • 2
    @Pawel Dyda A reset link can also be sniffed, if your email is getting sniffed i think having a temp password in your email is the least of your worries.
    – Viper_Sb
    Oct 28, 2010 at 15:57
  • That's why I wrote about security question. Oct 28, 2010 at 17:15

The comment is against sending the original password in email, not sending anything in email. If the institution can send the original password, that means they have it, and that's a security problem. The commenter was not arguing against sending a password through email, because that's pretty much necessary in most cases.

The proper way is to assign a new password that's usable once, for whatever reason. Perhaps it's already marked expired by the system, perhaps it just logs into a page to change the password that's dynamically generated once and only once, whatever.


The thing I like the best is for the application to send an email to the user on the registered email-address with a one-time link valid for X hours which provides a "Change password" page.

The user can then set the password as s/he likes without risking having it put in an email.


My credit card provider has a "forgotten password" option that asks you some security questions ( this is not immensely secure in itself but lots of banks do it ) and then generates a new code and gives you half on screen and emails the second half to you. That way you can't break the account without access to both the web page and the email address.

I have asked a little about this from a usability perspective a while back.

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