Valentino Volonghi aka Dialtone ha scritto: > On Fri, 04 Aug 2006 09:56:16 +0200, Manlio Perillo > <[EMAIL PROTECTED]> 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 _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
