By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,490 Members | 1,489 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,490 IT Pros & Developers. It's quick & easy.

Send Forgotten Password

P: n/a
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


Jun 16 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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:
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


Jun 16 '06 #2

P: n/a
AlexVN wrote:
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.


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.
Jun 16 '06 #3

P: n/a
> 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?
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.
The process does not require military level security but I would like to
keep stored passwords as hashes.


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
Jun 16 '06 #4

P: n/a
Colin McKinnon wrote:
AlexVN wrote:
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.


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.


What is the point of the new password field if the user never gets to find
out what the new password is?
Jun 16 '06 #5

P: n/a
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.
Jun 16 '06 #6

P: n/a
Colin McKinnon wrote:
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.


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.

Jun 16 '06 #7

P: n/a
>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.


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
Jun 16 '06 #8

P: n/a
Paul Lautman wrote:
Colin McKinnon wrote:
AlexVN wrote:
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.


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.


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


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.

Jun 16 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.