1

I'm currently designing a small website and I'd like to implement the "forgot your password?" feature. Here is my idea:

forgot your password web page will have this:

Email: (input box)
(button: "Make temp password")

On "Make temp password" button click:

  1. Sanitize email input for SQLi/XSS
  2. Check to see that the email address exists in the database
    • if not, tell user to make new account or check email spelling
  3. Create random password (ie “xh5MvQe”) and put it in database in the user’s temp password field.
    • overwrite if already exists. do not touch the main password. the user will be able to log in with two passwords for the next 48 hours.
  4. Get the current UTC time plus 48 hours and put it in the user's temp password expiry date field in database. overwrite if already exists.
  5. Send email to user with the temp password

My database has these fields for the user table:

(primary key) user id
name
nickname
(non null, unique) email
(non null) password (encrypted)
temporary password
temporary password expiration

Once the user has the password, they can log in and change their main password.

Question is: is this a secure way to implement this feature? My main concern is sending a plain text password via email. I've seen the other way of generating a link with email hashed/timestamp/random id as a GET parameter, but I don't see how that's any more secure. Please correct me if I'm wrong.

jb.
  • 9,921
  • 12
  • 54
  • 90
  • 1
    I'd agree that both methods are equally secure, and note that links in emails are clickable. – bkconrad Mar 12 '12 at 05:45
  • The steps you have outlined are just fine. You have no control over how the user manages their email address, but a great way to add some security is a security question before resetting the password. This may not be wise if some users forget that too, so its up to how you want it and whats more usable. – Andy Mar 12 '12 at 05:51
  • Just thinking out loud. But would it be too much effort to use 2 recovery passwords if your worried about emailing passwords? you could email one, and display one. That way you know the email hasn't been intercepted, because only the user requesting the password will have the second password. Almost like a "Something I have" + "Something I know" kind of thing. – Bradmage Mar 12 '12 at 06:56

3 Answers3

4

Read this: The definitive guide to form-based website authentication

It's bad to send the users any passwords, because you can't be sure if his machine/email account is/will be secure. If you generate and send a password, the user might not change it. You can't avoid to send some kind of identification token for recovery though, so an expiration date is a good idea.

Never store plain passwords anywhere. Use a salted hash. An attacker getting access to your database is bad enough, but it's even worse for users who used the same password for other services - and they always do this, silly users.

So, this is a way to avoid saving plain text passwords on a users machine:

  1. Sanitize email input for SQLi/XSS
  2. Check to see that the email address exists in the database
    • if not, tell user to make new account or check email spelling
  3. Create random recovery login token (ie “xh5MvQe”) and put it's hash in database in the user’s password recovery hash field.
    • overwrite if already exists. do not touch the main password. The user will be able to
      • log in with his old password, deleting the recovery hash.
      • log in with the recovery token passwords once, in the next 48 hours, which forces the user to choose a new password.
  4. Get the current UTC time plus 48 hours [...]
  5. Send email to user with the one-time recovery login token link.
Community
  • 1
  • 1
kapex
  • 28,903
  • 6
  • 107
  • 121
1

I think the psuedo system you have is secure, I would add a step 6 which would be to clear the temporary password when the user does change their actual password. If you are worried about the unencrypted Email - you need to make sure that the temporary password isn't available for up to 48 hours even after the user has changed their password successfully.

Ryan Kempt
  • 4,200
  • 6
  • 30
  • 41
0

This is quite unusual way.
Most of time a hyperlink being sent, not password itself.

A hyperlink which will let a user to enter another password.
Consists of email and expiration time, sealed with some hash.

Also I see no point in sanitizing email against XSS.
And "sanitizing email input for SQLi" sounds strange to me as a separate step. Isn't necessary preparation being a local part of SQL query creation? Why it happened to be part of the global algorithm?

So, to me it looks like 2-part algorithm:

  1. Ask a user to enter their email.
  2. Check to see that the email address exists in the database
  3. If so, send a hyperlink to that email

with a code like this

$salt  = "35onsoi2e=-7#%3%g03skl";
$time  = time();
$hash  = MD5($_POST['email'].$time.$salt);
$email = urlencode($_POST['email']);
$link  = "http://example.com/register.php?email=$email&time=$time&hash=$hash";

After clicking the link user lands on the restore password script, which

  1. Does verifications using the same algorithm of hashing.
  2. Checks the expiration time.
  3. if everything is okay, prompts a user to enter new password
  4. Resets password in the database.
Your Common Sense
  • 156,878
  • 40
  • 214
  • 345