Encrypted Passwords - Email forgotten passwords?

[bitwise]

If I store a user’s password in the database using a one-way encryption scheme, how can I send the user their password if they request it? Well, I can't. All I could do is reset their password; however, then anyone with simply their username could request the password to be reset. Now, this wouldn't actually comprise any account, but it could be very annoying to the user who gets their password reset.

What are some possible solutions to this issue?

Thank you.

 

[bitwise]

I've figured out a good solution to this.

In my "tblUsers" I have added the field:
TempChangePassword VARCHAR(32) NULL,

Now, when the user enters their email address to get their password reset, it randomly generates an 8-char password, stores it in the database in TempChangePassword, and emails the user a link that looks like this:

[URL unfurl="true"]http://www.site.com/reset.php?email=bla@bla.com&password=new[/URL]

Obviously, since that user only has access to their own email, they are the only ones that know what the new password is (i.e. "new" in this example). When the user clicks on the URL that script then checks that the password given in the url matches the TempChangePassword for this "email" account. If it matches, then the new password is encrypted, stored in the real password field in the database, and TempChangePassword is updated to NULL. If it doesn't match, then the reset.php scripts simply redirects to index.php and nothing happens.

Works good, and logically seems secure. If someone thought they were smart and did something like this:

[URL unfurl="true"]http://www.site.com/reset.php?email=bla@bla.com&password=gotcha[/URL]

The script would detect that "gotcha" does not equal what is actually set in TempChangePassword, which is "new", and the script would NOT update the password, and would simply redirect to index.php.

Looks safe and secure to me. Anyone see a problem?

 

[jpadie]

the normal solution to the issue in your first post is to substitute the 'something you know' with the 'something you have' (from a security perspective).

this means that the newly generated password would be sent to the email address that the user setup when first registering with the site. or even better, by SMS to a mobile phone. Since Email addresses are unique, they satisfy the 'something you have' limb of security best practice.

I typically do not regenerate passwords but provide a link in the email to allow one time (and time limited) access to a special page where a user can enter a new password.

 

[feherke]

Hi

I store a user’s password in the database using a one-way encryption scheme

To store the password encrypted adds minimum security. The password should be encrypted while it is transfered.

If your authentication mechanism does not include a challenge too, then I suggest to read "Login System" by Paul Johnston.

Feherke.

http://rootshell.be/~feherke/

 

[Olavxxx]

Why store it encrypted, if you also store it in plain text??
If they read what you post (man in the middle), they can post that string too, and then it does not matter if it's encrypted in the db, as they know your password in plain text.

If they however "root" your database, they can then check out what the password is, if its not encrypted.

If you then have a "unencrypted pass" field, they can read it.
Most "dumb" users use the same password "everywhere", so here is one issue!

If bob45 uses the password "secret" or maybe it's even the name of his dog, "bobby" and someone roots your db..

They then read bob45's password in plain text.
Then they can google bob45's username and login to his accounts everywhere.

I think that's the main reason to use encrypted passwords in the db, as it does not protect the transferral as much as it protects a leakage.

I think you also bear a responsobility for further abuse of a password, as most users will use the same password on multiple sites.

Rather make a password reset system, where he gets an email with a link. This link will have a unique id which can generate a random password and then email it to the users email account.

For further protection, you could demand that they have some kind of security question. However, I think its safe to say that if they can access the users email account, they can do "what they want".

my 2 cents...

Olav Alexander Mjelde

http://www.volvo-power.net

Admin & Webmaster