[Zope-PTK] PROPOSAL: A Confidence Mechanism in User Role Mana gement

[Christopher Petrilli]

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