[Twisted-web] [Nevow] new chapter about authentication

[Manlio Perillo]

Valentino Volonghi aka Dialtone ha scritto:
> On Fri, 04 Aug 2006 09:56:16 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> 1) The client ask to change the password
>> 2) The application ask the old password and the new one
>> 3) do the query:
>>   UPDATE Accounts SET password=md5(:new_password)
>>   WHERE password=md5(:old_password)
>>
>> The application developers can forget to invalidate the "old" session.
> 
> I remember you said the problem was stealing the password. I can't see
> how this is going to allow stealing the old password.

Yes, you are right. I'm a bit lost within the discussion.
The right query is:

UPDATE Accounts SET password=md5(:new_password)
WHERE username=md5(:username)

The attacher does not know (and it never needs to know) the "old" password.
It can simply ask the system to send a valid password to its email address.

>> Ok.
>> So this means that the development of new guard is goind to happen in
>> Nevow and *then* ported to web2?
> 
> Yes, unless web2 discovers a new and wonderful way to deal with this
> problem.
> 

Well, much of web2 developers are nevow developers. I'm wrong?

>> You can need to initialize some state in your Session.
>> class ICounter(Interface):
>>   pass
>>
>> class CounterSession(Session):
>>     def __init__(self):
>>         self.count = 0
>>
>>
>> sc = SessionManager.getSession(ICounter)
> 
>> I can now use this simple session to limit logins attemps.
> 
> This usecase is not a very good example of why it is a good idea.

I'm not an expert in this field, so I have used the first example that
come to my mind.

> But I think it may be required for OpenID and similar mechanisms.
> 
>> Well, of course an attacker will not use cookies at all...
>> But I can bind the session to the source IP address, using this value as
>> session key
>> (at least I would like to send an email to the site admin when having
>> 100 logins attemps from the same IP address).
> 
> I can't think of this feature in a pluggable way. If you want it just
> code it in your Session object. It's fairly easy to do.

Yes, but you have to handle the initialization code by hand
(self.count = 0).

>>> This is not enough reason anyway. You have to explain why it is a bad
>>> idea.
>>>
>>
>> I don't like the idea to have "authentication only" sessions.
>> SessionManager (and CookieFactory) is a general class that should not
>> live in guard.
> 
> Any _technical_ reason? importing a module and getting only the objects you
> need from it doesn't sound so bad to me.
>

Handling session initialization code better.
Only SessionManager knows when a session object is created and when
simply retrivied (the interface is the same: getSession).



Regards  Manlio Perillo