I have a pretty standard registration form. One thing I've decided to do away with is the requirement to enter the password twice, for usability reasons.

In order to mitigate the increased risk of inputting a wrong password by mistake, is it ok to send the password in the welcome email to the user? This would happen in the code that handles the form response. The password is then hashed (bcrypt) and stored, so cannot be retrieved in future.

My reasoning is that an attacker who has gained access to the user's email account can reset the password on this service anyway using the standard password reset tools, so storing a copy in their inbox is not any more of a security risk than having email-based reset.

Is there a flaw in my thinking?

  • 1
    @JonRhoades Why no? I'm interested as to why you think it's a bad idea.
    – fredley
    Commented Jan 2, 2014 at 10:15
  • 3
    @JonRhoades maybe you should elaborate a bit more on why it is actually bad rather than just rant. The question is valid and quite interesting IMO. Commented Jan 2, 2014 at 10:16

2 Answers 2


I see an issue in the fact you are sending their password in plain text across an unencrypted link. Anyone monitoring data transmission at any point between the users PC and your site would be able to capture their password.

If you sent a 1 use password that they then had to change when they logged in then that would be better.


To an extent your thinking is correct. If users can reset the password with access to the e-mail account then there's no great risk in the plain text password being in the e-mail account.

However there are other concerns with this. firstly if you send the password by e-mail it could well be transmitted in clear text over untrusted networks (you have no control over the e-mail path or storage), which could result in it being compromised.

Additionally there are possible scenarios where an attacker could have access to the text of users e-mails without necessarily having interactive access to their account. For example if an IMAP/POP client caches data on a local machine and the attacker has file access to that data.

Lastly you could have a security perception problem. Standard doctrine is that passwords shouldn't be recorded or stored in cleartext, so by breaking that you open yourself to accusations of poor security, regardless of whether it is or not .

Overall perhaps a better solution would be offer users the option to display the password as they enter it (as Windows 8 does). So by default it would be hidden but they can take an action (e.g. clicking a button) to show the password on-screen as they enter it, so they can confirm that they have typed it correctly.

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