Re: Re: WAYS OF AUTHENICATION - open discussion

> I've recently been working on almost the exact same authentication method. > The only difference is that when the login page is requested, instead of a > timestamp, I create a session variable called $token, and populate it with a > unique id string, generated like this (thanks, in part, to others on this > list): > > mt_srand((double)microtime()*1000000); > $token = uniqid (mt_rand()) . $HTTP_SERVER_VARS["REMOTE_ADDR"]; > > I also write the value of the token into a javascript function as a literal > string. Upon submission, the javascript function calculates md5(token + > md5(password)) and populates a hidden input variable called auth_token. The > server side then pulls the md5 hash from the database ($hashpwd) based on > the login name, and calculates $verify_auth = md5($token . $hashpwd). If > $verify_auth == $auth_token, the login is successful. > > As Dean's did, this scheme ensures that: > 1. the user's password is not sent in plaintext. > 2. the password hash that is sent is unique every time the user logs in > > It also ensures that there is very little chance anyone could create a valid > the password hash since each new session will generate a new random token. > > I would be very interested and grateful if anyone can help me poke holes in > this method. > > Joe As Manuel aptly put it, there seems to be nothing to prevent someone from swiping the same page and submitting the exact same values as a valid user did. In my case, I use a timestamp that's hashed into the password. When a minute has passed according to this timestamp, the whole page becomes invalid and a login is not allowed. I don't see how your scheme prevents such a thing from happening. Dean.