After users have registered on a website, should that website send both username and password in their registration confirmation email ?
-
11Don't end up on PlainTextOffenders, mentioned in Jeff Atwood's recent blogpost on hashing ;)– JeroenApr 7, 2012 at 6:01
-
You can also search for related questions on security.stackexchange.com if you are concerned with the technical implications.– konturDec 3, 2012 at 13:39
2 Answers
A system should not store the user's password in retrievable mode. This could be done adding salt (a meaningless string of letters and numbers, which doesn't change) and then hashing the whole string before saving to a persistent storage.
When the user signs into the system, the same route is taken to make sure that the password is correct. (password + salt) + hash = stored string.
Now this means that the system does not know the password, and therefore cannot send it to the user. Instead the user can receive a confirmation email where the user validates her email address. If the password is lost, we shouldn't send the password to the user. We should send a link to a unique page, valid only once, where the user can change the password, if the password were forgotten and requested by the user.
Please don't send passwords in email. Username is ok to send, though.
-
@BenDurnell Thanx! I've recently been requested by our customers to show user password on the admin pages, and I had to explain why not. Apr 7, 2012 at 9:31
-
6If you're explaining it, do mention that "we don't store your password in a way where we can view the original password - this way, hackers can't either". This is not really a UX question, more a security question though.– KonerakApr 7, 2012 at 11:20
-
2I don't see why this is appropriate, personally. Sending the email is something that happens on registration, and at registration you will have the user's password, because (crucially), it hasn't touched the database yet. Hashing and sending the password out at registration time are not mutually exclusive in any way. I'd still argue that sending the password out to a third, potentially insecure, party is a Bad Thing, but that's for different reasons!– PhoshiApr 7, 2012 at 18:36
-
5@Phoshi - Aside from other considerations, sending out the password at registration sets the precident that you can send out the password, so you'll get user complains when you don't later on. Nontechnies are not going to understand the difference in contexts.– BevanApr 7, 2012 at 20:48
-
2@Bevan; Absolutely, I agree it's a bad idea for other reasons, but I don't think this entirely technical consideration is one of those. It's an important point, but I don't think this is the place it needed to be made.– PhoshiApr 7, 2012 at 22:18
From a user experience point of view I would say it is nice to get your nickname confirmed in a registration email, but sending the password along might create the impression of lax security.
A user will never require to get their password emailed, if you set up a password reset mechanism that only sends password reset links to an user's email (in case they have forgotten their password). It requires more clicks, but users are becoming more and more tech-savy and know to appreciate improved security as part of their usage experience of your service.
-
1Forget 'lax' security. Sending a password in plaintext to someone's email is not just a huge major red flag (and would cause me to immediately change my password to something I don't use anywhere else for anything) and daft, but also means they're storing it in plain text (or a retrievable format), meaning if there are any other vulnerabilities (which is highly likely if they're handling passwords in plaintext...) a hacker could just grab and decipher emails from their database. Feb 21, 2013 at 15:51
-
You are right. I was more thinking from the point of view of an average user seeing their own password in an email. Users knowing about the implications of a stored plaintext password obviously screem and screetch at the sight of one.– konturFeb 21, 2013 at 20:32
-
@Anonymous It is not sure that the password is stored in plain text. I mean, not if it's a new account e-mail as the password is sent in plain text to the server the first time around. Of course, that's why you have ssl on your connection but it perfectly feasible to send a plaintext password to a user one time while storing it with hash and salt... Jan 13, 2015 at 16:57