Is it better when a user forgets their password to have them reset their password or to just send the lost password back to them?
A:
It is more safe to reset the password, since a third party could intercept the mailed password.
Edit: By reset, I assume you mean the common pattern of sending the user a token which allows the user to define a new password. Obviously if you just generate a new password and send it in the mail, it is just as insecure as just sending the original password. The token should of course only be usable once, otherwise it will be just as good as a password.
Only risk here is that a third party intercepts the token and change the password before the user does. This is lower risk than sending the password, since an intercepted password will be useful as long as the password is in use, while the token will only be useful once, and you will discover if someone has used the token.
Note that the highest risk is probably not people eavesdropping on the email traffic, but rather someone looking through your mail later, or hacking into your webmail account, so it it really bad to have still-valid passwords in your mailbox.
JacquesB
2009-09-20 09:48:51
So how will the user get a hold of the reset password, given that mailing is insecure ? :)
Zed
2009-09-20 09:53:15
@Zed: send a link to the user that contains a random single-use value (which you remember) so that when they click on it you can reset their password and send them a new one (over https).
Greg Hewgill
2009-09-20 09:57:16
@Greg: That's the point. There is no difference between mailing a "random password", or a "random value that the user can use to...". You use them both to _temporarily_ identify the user. Third party can tamper with either of them.
Zed
2009-09-20 10:00:45
Well, when the only thing the site knows for certain about the user is their email address, we won't solve that until we solve the encrypted email problem, will we?
Greg Hewgill
2009-09-20 10:12:38
Exactly. In short, if you don't trust e-mail you lost. If you must trust e-mail, there's no point in playing around with random links and whatever, it's not safer than sending a new password.
Zed
2009-09-20 10:24:51
Big difference, but not security-wise - but usability-wise. It sure is easier for the user to get a link to just click on and be presented with the "select a new password" dialog directly, than a temporary password the user has to copy and paste (or type) into somewhere else and then hit enter... a lot more steps that aren't needed ^^ (but should also be there as a fail-safe)
Oskar Duveborn
2009-09-20 10:45:08
@Zed: Unless the “random password” is not just a temporary password that must be changed, there is a difference between the “random token to change the password” and the “random password” indeed. Because the user might want to keep the “random password” that’s been sent to him and maybe forgets to delete the e-mail. But the random token will in the best case only be usable once for that specific password change and only valid for a short period of time.
Gumbo
2009-09-20 10:47:14
@Gumbo: So do not allow the user to keep the password. Force him/her to change it after first login.
Zed
2009-09-20 10:50:17
+31
A:
Sending them lost password implies that you're keeping them in plain text or encrypted in two-way encryption which is not safe.
I'd suggest following Wordpress mechanism for reseting the password:
- Send a link with confirmation of password reset
- Follow confirmation link to the page which would generate random password and send it to the user
- Let user login with new password and change it to something better remembering.
Eimantas
2009-09-20 09:49:57
I was thinking to send a reset password even though it seems easier for the user to send them there old password back.
2009-09-20 09:52:33
If anything, it's a matter of trust - would you really want the administrators of every site you use knowing what passwords you choose? Sure, ideally people would use different passwords for every site, but few actually do - it's too much of a hassle.
Amber
2009-09-20 10:12:44
Just add a little bit to Eimantas' reply. For security, the server should never save a user's password in plain text. It should save the one-way encrypted password. When a user login, the client should encrypt the password with javescript and send the the encrypted string to the server. This is a bit like how Unix login works. Frequently a user uses the same password for different website. If you keep it in plain text, you will get the access to all of them. As a user, I would deeply worry about that.
2009-09-20 10:13:59
@lh3 Encrypt it using JavaScript on the client and then send it to the server? Are you serious?
Thiyagaraj
2009-09-20 10:25:41
@Thiyagaraj, At least it's safer than sending the password in plaintext.
strager
2009-09-20 10:38:56
hashing a password with Javascript has little added security. Security should be done on the server side, with SSL to protect he client-server communication. Javascript is ill suited for the job.
Jacco
2009-09-20 11:18:25
One more bit. I entirely agree SSL is more secure, but I still feel more assured if the server does not know and thus does not store my password. Storing passwords in a database on the server side still means some developers may know my password, which makes me feel unsafe.
2009-09-20 12:43:11
Only the Hash of the password should be stored; the passwords themselves should NEVER be stored on any server.
Jacco
2009-09-20 15:52:05
+14
A:
You shouldn't be able to send back the password in the first place. Your best chance is to generate a random one-time-use password, and send it to the user's registered e-mail address.
You can deploy security questions (like "your first dogs name") and other mysticism, but I believe users tend to forget answers to these even more than their passwords, putting you back to square one.
Zed
2009-09-20 09:51:34
If you do use (in)security questions, though, they MUST NOT be treated as a backup password, but only as gatekeepers of access to a password reset mechanism. Otherwise you get your email account broken into when someone looks up the high school you went to and tries it as an answer for "Where did you meet your spouse?" (as happened to Sarah Palin last year).
Dave Sherohman
2009-09-20 10:46:45
But it is important to send a random password only after a initial confirmation email. If you miss this, a malicious person can click on the request password button, enter you email address leaving your account inaccessible. If you want to login with your original password without checking email first, leads to a login failure. This is bad user experience and annoying. This technique used by a bot script can perform a denial-of-service for each known email address using the service.
Joker
2009-09-20 12:18:27
+5
A:
Many users use the same password across many websites. To respect the people's privacy it is recommended to always store passwords one-way encrypted with hash functions like SHA-256 or MD5. But you should not use them without any additional salt, since dictionary attacks can simply be performed on those passwords. Taking care of users privacy forms the basis of a trustful relationship between you and your customers.
I also recommend the password resetting mechanism mentioned by Eimantes. The confirmation email message is the main task in this process. Always let the user confirm his password reset request to avoid fake requests lead to an inaccessible account.
Instead of computing a random password, you could forward the user to a page where he can enter a new password.
Also keep in mind that sending passwords over http without ssl is very insecure, especially in public networks like wlan hotspots. Take a look at message authentication methods like HMAC in combination with Diffie-Hellman-Key-Exchange. Or at least use an additional hash+salt function during login.
Joker
2009-09-20 10:34:41