|
|
Posted by Colin McKinnon on 12/18/99 11:50
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.
Navigation:
[Reply to this message]
|