Send Forgotten Password

Hello,
I am new to PHP and am working on a login system for my site,
currently supplied passwords are passed to MySQL and stored as md5 hashes,
my question is :- seeing as md5 is 1 way only what would be the best way to
implement a 'Forgotten Password' system whereby the user supplies an e-mail
address and the password is mailed to the user?

The process does not require military level security but I would like to
keep stored passwords as hashes.

I have an idea on how it can be done but I would like to hear a few other
opinions

re: Send Forgotten Password

Katash,

Generally, when passwords are stored as hashes, the "retrieve password"
option is logically impossible. The "Reset password" option is used
instead, when the new password is mailed to the user in case when he
forget the password.

Sincerelly,
Alexander
http://www.alexatnet.com/

Katash wrote:[color=blue]
> Hello,
> I am new to PHP and am working on a login system for my site,
> currently supplied passwords are passed to MySQL and stored as md5 hashes,
> my question is :- seeing as md5 is 1 way only what would be the best way to
> implement a 'Forgotten Password' system whereby the user supplies an e-mail
> address and the password is mailed to the user?
>
> The process does not require military level security but I would like to
> keep stored passwords as hashes.
>
> I have an idea on how it can be done but I would like to hear a few other
> opinions[/color]

re: Send Forgotten Password

AlexVN wrote:
[color=blue]
> Katash,
>
> Generally, when passwords are stored as hashes, the "retrieve password"
> option is logically impossible. The "Reset password" option is used
> instead, when the new password is mailed to the user in case when he
> forget the password.
>[/color]

But bear in mind that, if trivially implemented, this *changes* the password
and can therefore be used as a DOS attack against the user.

A better method is:

In the database have columns for an old and new password for each customer.

When the customer logs in (presenting userpass), if the new password is
blank, compare userpass with old password to determine access.
If the new password is not blank, compare new password with userpass - if
they match, set old password = new password, and new password = null.

If the new password is not blank and does not match userpass, compare
userpass with with old password. If it matches then leave new password as
it is.

If a request comes for a new password, calculate the new password for the
user, update the new password in the database, and send out the old
password.

HTH

C.

re: Send Forgotten Password

> I am new to PHP and am working on a login system for my site,[color=blue]
>currently supplied passwords are passed to MySQL and stored as md5 hashes,
>my question is :- seeing as md5 is 1 way only what would be the best way to
>implement a 'Forgotten Password' system whereby the user supplies an e-mail
>address and the password is mailed to the user?[/color]

Keep in mind that the "Forgotten Password" system can and will be used
to mail-bomb a user with his password if you let it be used too often.
[color=blue]
> The process does not require military level security but I would like to
>keep stored passwords as hashes.[/color]

The point of keeping stored passwords as hashes is to make it impractical
to get the plaintext password. This is somewhat contrary to the objective
of being able to recover the password. You could keep both. In that
case, why keep the hash?


Gordon L. Burditt

re: Send Forgotten Password

Colin McKinnon wrote:[color=blue]
> AlexVN wrote:
>[color=green]
>> Katash,
>>
>> Generally, when passwords are stored as hashes, the "retrieve
>> password" option is logically impossible. The "Reset password"
>> option is used instead, when the new password is mailed to the user
>> in case when he forget the password.
>>[/color]
>
> But bear in mind that, if trivially implemented, this *changes* the
> password and can therefore be used as a DOS attack against the user.
>
> A better method is:
>
> In the database have columns for an old and new password for each
> customer.
>
> When the customer logs in (presenting userpass), if the new password
> is blank, compare userpass with old password to determine access.
> If the new password is not blank, compare new password with userpass
> - if they match, set old password = new password, and new password =
> null.
>
> If the new password is not blank and does not match userpass, compare
> userpass with with old password. If it matches then leave new
> password as it is.
>
> If a request comes for a new password, calculate the new password for
> the user, update the new password in the database, and send out the
> old password.
>
> HTH
>
> C.[/color]

What is the point of the new password field if the user never gets to find
out what the new password is?

re: Send Forgotten Password

I the system I had in mind did involve 'resetting' password, I just wanted
some ideas on how best to implicate it and the associated risks.

Thanks all.

re: Send Forgotten Password

Colin McKinnon wrote:[color=blue]
> A better method is:
>
> In the database have columns for an old and new password for each customer.
>
> When the customer logs in (presenting userpass), if the new password is
> blank, compare userpass with old password to determine access.
> If the new password is not blank, compare new password with userpass - if
> they match, set old password = new password, and new password = null.[/color]

Another common way to do this is to create separate table with two
columns, one holding a random string and the other the user name. A new
record is inserted when the a request for password reset is made. The
random string is then placed into a URL and send to the user's e-mail
address. When he clicks on it, he ends up at a page where he can enter
a new password. The script will use the random string to look-up the
account.

re: Send Forgotten Password

>I the system I had in mind did involve 'resetting' password, I just wanted[color=blue]
>some ideas on how best to implicate it and the associated risks.[/color]

Keep in mind that a "forgotten password" link can be used to mail-bomb
a user with emails giving them links to reset the password, regardless
of whether anyone ever knows or tries to use the password ever
again.

If you're emailing the user a link to use to reset his password,
keep in mind several things:

- The link should expire after a relatively short period of time (e.g. 3 days)
- You should limit the number of such active links at a time for any one
user (but the limit probably shouldn't be *1*, as the first one may get
lost in the user's spam filter).
- Use good random numbers as identifiers for the link, preferably not based
on the time the "forgot password" link was clicked and not based on
user personal information.
- The link should expire immediately if it is used successfully.

Gordon L. Burditt

re: Send Forgotten Password

Paul Lautman wrote:
[color=blue]
> Colin McKinnon wrote:[color=green]
>> AlexVN wrote:
>>[color=darkred]
>>> Katash,
>>>
>>> Generally, when passwords are stored as hashes, the "retrieve
>>> password" option is logically impossible. The "Reset password"
>>> option is used instead, when the new password is mailed to the user
>>> in case when he forget the password.
>>>[/color]
>>
>> But bear in mind that, if trivially implemented, this *changes* the
>> password and can therefore be used as a DOS attack against the user.
>>
>> A better method is:
>>
>> In the database have columns for an old and new password for each
>> customer.
>>
>> When the customer logs in (presenting userpass), if the new password
>> is blank, compare userpass with old password to determine access.
>> If the new password is not blank, compare new password with userpass
>> - if they match, set old password = new password, and new password =
>> null.
>>
>> If the new password is not blank and does not match userpass, compare
>> userpass with with old password. If it matches then leave new
>> password as it is.
>>
>> If a request comes for a new password, calculate the new password for
>> the user, update the new password in the database, and send out the
>> old password.
>>
>> HTH
>>
>> C.[/color]
>
> What is the point of the new password field if the user never gets to find
> out what the new password is?[/color]

Doh! Last paragraph should read:

If a request comes for a new password, calculate the new password for
the user, update the new password in the database, and send the unencrypted
new password to the user.

(The point being that if person B claims to be person A and asks for a new
password, person A can log in using either their old (legitimate) password
or the unsollicited one which is subsequently mailed out to them).

C.