17

After users have registered on a website, should that website send both username and password in their registration confirmation email ?

Benny Skogberg
  • 54,996
  • 22
  • 140
  • 241
Sarawut Positwinyu
  • 3,039
  • 4
  • 22
  • 29

2 Answers2

37

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.

whatsisname
  • 379
  • 1
  • 9
Benny Skogberg
  • 54,996
  • 22
  • 140
  • 241
  • @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. – Benny Skogberg Apr 07 '12 at 09:31
  • 6
    If 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. – Konerak Apr 07 '12 at 11:20
  • @Konerak That's true that its much harder for hackers to read the password, still if the system is connected to the internet it isn't 100% secure. But that might be to much information for a customer to handle (if they don't ask about it). And yes, this is on the outer boundries of the scope of User Experience, but I feel password handling is part of UX, at least periferial. Thanx for the tip! – Benny Skogberg Apr 07 '12 at 12:57
  • 2
    I 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! – Phoshi Apr 07 '12 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. – Bevan Apr 07 '12 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. – Phoshi Apr 07 '12 at 22:18
  • so, reasons not to send would be:
    • the impression of lax security
    • sets the precedent that you can send out the password
    • potentially insecure
     – Bobby Tables Dec 03 '12 at 13:59
  • I don't understand this answer, I agree that passwords have to be encoded (with a salt), but this is a completely different problem than sending the password in the confirmation email. – A.L Feb 20 '14 at 13:20
3

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.

kontur
  • 7,644
  • 3
  • 25
  • 50
  • 1
    Forget '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. – Anonymous Feb 21 '13 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. – kontur Feb 21 '13 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... – Philippe Gilbert Jan 13 '15 at 16:57