40

I can imagine both ways - send / not send and still make it secure enough inside application.

For instance: I get the password from "Enter your password" field, store it in email template and then save it securely (only its hash) in database

  Hi, <username>
  We just registred you at our super awesome page.
  Your password is <entered password during register>
  Yada yada blah blah blah

But having second thought about it, I know for sure, that experienced users know that if a site sends you password in plain text, that site has definitely some security issue (= if you hack database, you will see users and their passwords)

  Hi, <username>
  We just registred you at our super awesome page.
  We saved your password in super safe way, so we can only reset it at any given time
  Yada yada blah blah blah

I would like to hear some insights on which one is better from user perspective.

EDIT After third answer in style "do not store password plaintext" I want to make something clear:

  • I woud FIRST send e-mail and THEN hash the password in database in secure way. There is no way I would store passwords in DB unencrypted (unsecure). This is really only about if I should send the password back to user or not.
Improve this question
11
  • 36
    Do it and you will find yourself on plaintextoffenders.com
    – Philipp
    Commented May 7, 2014 at 14:38
  • 11
    While the conclusion in "experienced users know that if a site sends you password in plain text, that site has definitely some security issue (= if you hack database, you will see users and their passwords)" is true, the reasoning is not: A site that properly does not store any passwords, but only appropriately stored password hashes, in its database, is not susceptible to the described hacking of the DB, yet it still handles the actual password at the time of user registration and could send out an e-mail just then. The security issue is that it sends the PW in a (plain text) e-mail.
    – O. R. Mapper
    Commented May 7, 2014 at 16:16
  • 5
    If you're concerned about a naive user forgetting the password they registered with, you might include instructions on how to reset your password in the "congrats for registering" email. Tumblr goes so far as to put a "forgot password" link on every email they send!
    – Jim Dagg
    Commented May 7, 2014 at 18:50
  • 13
    @user1737909: Storing a password in plaintext is really bad. Storing it in plaintext on an unknown number of unknown email servers between you and the recipient is arguably much worse than storing it in plaintext on your own database server.
    – Iain Galloway
    Commented May 8, 2014 at 12:15
  • 4
    Nitpicky note: Do not store encrypted passwords, but rather store hashed passwords. There's a subtle difference...
    – apnorton
    Commented May 8, 2014 at 14:59

10 Answers 10

Reset to default
95

No - It is a bad idea:

a. Storing password as plain text instead of hashed with an individual salt. More details here and here.

b. Emailing a password, as:

b.1. emails are transmitted unencrypted over the Internet. More details here and here.

b.2. Users could open up the email and accidently expose their plain text password to someone standing next to them/behind them/a camera.


Also, from a technical point of view, if you attempt to email something without storing it to a database first and the operation fails (network problems, server problems, software problems), then you should be able to pull the pending operation from the database and retry it, otherwise your system is left in an inconsistent state (e.g. email was sent, account was not created or account was created, email was not sent).

Improve this answer
7
  • 4
    keep away the storing: Imagine it as if I first put the password to e-mail and THEN hash it in my database... BTW, I did not understand the (b) - could you please make it more clear?
    – Pavel Janicek
    Commented May 7, 2014 at 11:58
  • 2
    now I get it: In other words: Even when I store it later really securely, by sending un-encrypted password, I am at risk, that someone else will listen to the communication. Correct?
    – Pavel Janicek
    Commented May 7, 2014 at 12:15
  • 32
    @PavelJanicek You could think about it like this: instead of storing the password unencrypted in your own database (which is bad), you have stored it unencrypted on an unknown number of email servers and clients in unknown locations (which is worse).
    – David Z
    Commented May 7, 2014 at 16:25
  • 1
    You could overcome the 'plain text' problem with a simple GD image, just make a image of the text. Also, I sometimes add "We only send now becasue not encrypted, cant do another because encrypted then". Though 2B is a reason, IMO not a very big concern, but thats me
    – Martijn
    Commented May 8, 2014 at 9:14
  • 2
    @PavelJanicek you're still storing it in plain text - on your mail server, the recipient's mail server and potentially many other places depending on the recipients email configuration. Even if you generate an image (bad idea for reasons given above) you're still spreading the password around on your systems, perhaps as text, perhaps as an image, through code that's not designed for password security, completely unnecessarily. Plus it's extra overhead for you for no real benefit.
    – Chris H
    Commented May 8, 2014 at 10:26
35

Passwords should not be stored in plain text anywhere including the users email inbox. What happens if his email is compromised or if he's entered the wrong email address and someone else receives the password?

Improve this answer
8
  • thats good question. Did not consider this when thinking about it. Thanks for it!
    – Pavel Janicek
    Commented May 7, 2014 at 12:47
  • 1
    The issue with the wrong email address will also let the wrong user reset the password if it wasn't emailed in plain text, unless the reset password uses high quality security questions to prevent this.
    – Danny Varod
    Commented May 7, 2014 at 13:41
  • @DannyVarod but an archived mailbox will include the password allowing the attacker to log in without needing real-time access to the mailbox (which resets require)
    – ratchet freak
    Commented May 7, 2014 at 15:27
  • @ratchetfreak How is that connected in anyway to what I wrote? I was addressing the "wrong email address" issue which is problematic whether the password was sent or not. My point was that you must validate email addresses at sign up.
    – Danny Varod
    Commented May 7, 2014 at 15:46
  • 1
    @DannyVarod Another user gaining access to freshly created account does not sound half as terrible as the one who gained actual password for this account for the chances are the same password may have been used somewhere else.
    – Cthulhu
    Commented May 7, 2014 at 19:04
17

Please don't.

I snagged (myfirstname)@gmail.com several years ago. There are a few other people who share my first name, and they occasionally forget that their email address is not (myfirstname)@gmail.com. As a result, I have received quite the collection of personal information about other people with my name. I've received data like passwords, snailmail addresses, dates of birth, Social Security Numbers (or equivalent for those ladies not in the US), answers to security questions, and so much more. I even had to call one woman's bank to get them to stop emailing me her bank statements.

You might think that your user knows their email address. I would like to think that this is the case too. However, given the amount of personal information I have received about various other women named Nadyne, it's not as true as we would like it to be.

Improve this answer
8
  • I hope your real first name is not Nadyne - otherwise you just put your email address out there for the world. Let's hope bots are not clever, and users on this site have integrity. Good story.
    – Floris
    Commented May 11, 2014 at 14:32
  • 2
    @Floris Her email address is publicly listed on her website. But in general, I don't think there's any reason for non-anonymous users to fear their email being publicly listed. What's the possible harm? It seems like a hold-over from the days before we had effective spam filters.
    – Jeremy
    Commented May 11, 2014 at 23:47
  • 1
    My real name is Nadyne. My profile links to my website, which has various methods to contact me. Even if it didn't, my name is unique enough that a search on my first name turns me up on the first page of results. I've had my email address for long enough for the spambots to have added it to their lists long ago. I suppose it's possible that someone's bot is smart enough to figure out what (myfirstname) in this post maps to, but I'd be surprised if that much effort was put into it. Given that I make no attempt to hide my identity here, what is the concern?
    – nadyne
    Commented May 12, 2014 at 5:23
  • @nadyne - your spam filters must be much better than mine. I recently made an innocent request on a website that required an email, and my inbox traffic has quadrupled since then. Maybe I'm just paranoid. Yes my real name is Floris... I don't have a public website. Your blog is good. I am not that interesting.
    – Floris
    Commented May 12, 2014 at 21:23
  • 1
    @Floris, not sure who your email provider is, but I'm with gmail and can count on one hand the number of spam messages that have made it through to my inbox over the last couple of years. I would consider this a solved problem.
    – Mike Chamberlain
    Commented May 12, 2014 at 22:46
9

There's no reason to send the user a copy of their password when they register for your service.

No reputable website does that. When you join Facebook or StackOverflow, you don't get emailed your password after joining. It's just not necessary. If a user has problems remembering their passwords, they can use secure password storage apps to remember their passwords.

Provide the typical reset password option (where you email them a link to reset their password) and you'll be good.

Improve this answer
2
  • If a user forgets their password and requests a "refresh", it is common to email them a one-time-only password that they must immediately change. Of course, someone could intercept that email and do some damage before another password can be issued. Doing it on an on-site SSL web page might be reasonably secure, but even then, if the email giving the session key (the only proof of who is using it) is intercepted, someone else could use that link before the intended user can. I'm not sure there is any foolproof way to do this over the network, that a determined bad guy couldn't steal.
    – Phil Perry
    Commented May 9, 2014 at 16:01
  • 1
    From a user experience standpoint, though, that's pretty rough. You're basically saying "here's a gibberish one-off password, please copy it and login with it and then change to another password" whereas the link -> password/confirm password flow is a bit easier on the user. Whether they have this gibberish password or the link (especially if the username is the user's email address), it really won't matter security wise. Perhaps where there are usernames that are not email it may help, but where the email address is the username, won't change anything except more actions required.
    – Robert
    Commented May 9, 2014 at 18:21
5

I think that unless they have been living under a rock for the past while, the average user should be aware that they shouldn't assume that email is a secure form of communication. There have been a lot of high profile things in the media (Snowden revelations, Heartbleed) relating to online security.

If a user isn't aware of this they aren't likely to expect a password in an email anyway. If a user is aware of this they are likely to think it is a bit dodgy to receive a password like this. I would err on the side of caution with this one, and avoid emailing passwords.

Improve this answer
1
  • I believe the average user above 40 years old has absolutely no clue about email security, and would not question a password sent by email. Not saying one should do it though.
    – maxbellec
    Commented Jun 15, 2022 at 10:07
2

What about sending the just a part of the password, like the first and last character(s)? OMGSWAGpasswordBlazeIt420!!! could be returned as O***!

This way, you give people a hint to their password without giving hackers/bots too much help. Just make sure you do not return the same amount of characters.

Improve this answer
3
  • I can think of only one problem: what if different organizations reveal different characters? You might have one that shows O***!, another that is OMG*** or 420!!! or all sorts of different variations. However, this is a much better idea than sending the whole password, although I'd rather not be told what my password is because I just typed it in before I got the email.
    – Justin
    Commented May 12, 2014 at 7:05
  • From an UX standpoint, i think it doesn't really matter which part of the password is returned, as long as it helps you remember what it is. It could theoretically be a security issue, but only if you a) use the same password for everything, b) all the revealed characters contain a large part of the entire password and c) somebody has access to your inbox. If you do not like users getting their partial password back immediately, just store the first and last characters in an encrypted or obfuscated way for future reference. This should strike a balance between UX and safety.
    – Tom
    Commented May 12, 2014 at 13:16
  • This is a really good and interesting idea. It's like the way sites with two-factor authentication will say "We've just sent a text message to your mobile phone number xxxxx xxxxxx34". First two and last two characters will usually be enough to prompt recall of the password, and not enough to allow an interceptor to figure it out. I like it a lot.
    – AlexC
    Commented May 14, 2014 at 10:09
0

Websites before 2000 usually did this way

  • ask for username and password; email is not necessary
  • password is stored in plain text and registration confirmation email contains the password
  • the password can be retrieved back by answering the security question correctly

This fashion has been abandoned since about 2000, so one should not follow this old fashion any more.

Improve this answer
1
  • 2
    keep away the storing: Imagine it as if I first put the password to e-mail and THEN hash it in my database.
    – Pavel Janicek
    Commented May 7, 2014 at 12:08
0

Assuming that the website has a “forgotten password” function to send a link to reset your password, I see no problem with them email me my password, as they are no more secure then my email system anyway.

It is also a nice remember to use a different password for each website, as you must assume that passwords are stored as plain text, whatever we may think about it.

However I would rather they emailed me a random password and did not ask me to enter a password when registering, so there are less issues with users reusing passwords.

Improve this answer
2
  • True, you can make no assumptions about the security of an ID/password system. Hopefully they're not so stupid as to store passwords in plain text, but you never know. And it's a bad idea to reuse passwords, as getting hold of one could let a bad guy into multiple accounts of yours. Emailing a permanent password to you is still subject to theft, even though the damage will be limited to one account (say, your bank account!).
    – Phil Perry
    Commented May 9, 2014 at 16:04
  • @PhilPerry, 99% of websites that I use will email a password reset link to me. My bank is in the 1%!
    – Ian
    Commented May 9, 2014 at 22:38
0

My ideas on this as a web developer and designer:

  1. For security you must encrypt password, but you can still send the un-encrypted one to the user if you really need to. You can do so by preparing the email with the plain password and sending it right before encrypting it and storing it.

  2. It is not the best idea to send a plain user password in an email as it could be compromised, however you could provide it as an option for the user in the form of a checkmark, could improve user experience. You could also remind the user to write their password down as they type it, to avoid losing it.

Improve this answer
1
  • 2
    This fails on basic security because, as a web designer (or server admin), you should have no way to recover the user's password. If you can decrypt it then so can a hacker who breaches your network and finds the decryption key in your code. As described in countless places on the web, you should use a salted hash to store a representation of the password. As for encouraging the user to write the password down, this is terrible advice and as a web designer you should know better.
    – Mike Chamberlain
    Commented May 12, 2014 at 22:53
0

Technically, password should never exist anywhere in open form, except at field where user enter it.

Security systems are ok having only a hash of the password, which ensures ability of system to say is password valid or not.

To mail a password to user in raw form means this password will be processed by multiple systems, and each of them may potencially expose password to unauthorized systems and persons.

But in terms of usability, it's sometimes worth to let user see password with his own eyes . Typical ways to do so are:

  1. Give user an option to show password instead of showing stars.

  2. Display password of the user immediatly after he entered it. This approach is useful for 'master passwords'.

This is handy to avoid common password mistakes like 'CAPS LOCK' or wrong keyboard locale.

There is also deprecated approach to ask user to re-enter password, but it just not works - because most times user will enter password again in wrong locale or with CAPS, and he will be unable to login in system with password he had in mind.

Improve this answer
3
  • How about passwords hashed in Javascript and never sent over the network as plain text, even if the link is SSL? I've seen applications do that, but I'm not sure if that adds anything over transmitting a plain text password to the server over SSL. If the link is not SSL, it's probably something of an improvement over sending the plain text password to be hashed on the server. Comments?
    – Phil Perry
    Commented May 9, 2014 at 16:08
  • @PhilPerry That's an interesting idea. You would have to expose the users' salt to them before they were authenticated though. An attacker could easily get a hold of the salt of a targeted user, then they could perform a dictionary attack.
    – Paul
    Commented May 9, 2014 at 19:39
  • SMF (Simple Machines Forum) chooses not to use (much less require) SSL for sign-on. In Javascript they hash the just-entered password (with salt... the first few letters of the ID, IIRC) and send the hash in the clear. I'm not sure how much they gain with that, beyond blocking very casual thieves. Maybe they do something else too so that simply injecting an ID and a stolen hash into the stream doesn't work for a thief.
    – Phil Perry
    Commented May 12, 2014 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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