Mailing List Archive

On 2/9/00 11:47 PM, Rob Page at rob.page@digicool.com wrote:

>> So, if cleartext is less trustworthy because it's sniffable, it
>> follows that using cleartext once compromises the secure
>> channels as well, and so they should be no more trusted than cleartext
> UNTIL
>> the password's been changed. Oh. But, if you are now
> less-than-confident
>> of the remote user, you can't let them change the password so as to
> become trusted
>> again! D'oh. Seems like a Catch 22, I must not be getting something.
>
> This is a valid point. This is why many sites have you login over SSL.
> Perhaps they assign you an expiring cookie which you can carry around
> and over unsecure channels. Ideally, password specification and
> password presentation are all done over secure comm - then you don't
> have to discount the confidence in the password as an accurate
> authentication mechanism.

This is what I was mentioning at the bottom of another email, which is that
you have the following chain of events:

* User is presented a login form over HTTP
* Form is POSTED via SSL, which sets a cookie in the browser
* Cookie is volatile and used for auth during session

The cookie must be something non-guessable, so I proposed the following:

base64(sha1(username + ip_address + random_int))

This gives you a token that should not be "guessable" and in addition, as
long as you keep the random integer chosen around, you can validate that the
cookie is valid using 2 options:

* Recompute auth information and compare (the correct way, long story)
* Store IP address and precalced cookie, and compare those.

Chris
--
| Christopher Petrilli Python Powered Digital Creations, Inc.
| petrilli@digicool.com http://www.digicool.com