petrilli at digicool
Feb 10, 2000, 7:08 AM
Post #2 of 2
(84 views)
Permalink
|
|
Re: [Zope-PTK] PROPOSAL: A Confidence Mechanism in User Role Mana gement
[In reply to]
|
|
On 2/9/00 11:47 PM, Rob Page at rob.page [at] digicool 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 [at] digicool http://www.digicool.com
|
