[Twisted-web] [Nevow] new chapter about authentication
manlio_perillo at libero.it
Fri Aug 4 02:56:16 CDT 2006
Valentino Volonghi aka Dialtone ha scritto:
> On Thu, 03 Aug 2006 20:26:13 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>>> You must autogenerate a new one and then send it, and if it's like that
>>> you 'just' lost an account and not a password.
>> One can simply update the entry in the database, without having the
>> application code know about this (but I'm not sure here, I have to do
>> some tests since I'm interested in this feature).
> Update which entry in the database? The password? Just ask to provide
> the old one or simply don't put the old one in the page. Again: how are
> you going to _show_ a passoword that you don't even know? it's hashed.
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)
The application developers can forget to invalidate the "old" session.
>> authenticator or authentication token.
>> On papers (like http://pdos.lcs.mit.edu/cookies/pubs/webauth:tr.pdf) and
>> the OWASPGuide they use this term.
> Ok, it's the session ID. Let's restate your sentence now then: you said
> that sessions are a bad fit for authentication.
> This is true only when you talk about cookies. Sessions serverside are a
> perfect way to deal with authentication and they should not be
> accessible by the user.
Ok, but sessions cannot exists without cookies (or other solutions to
keep state beetwen successive requests).
The problem is that "GuardSession" are not simply session!
They allow an user who only know the session ID to authenticate into a
>> Well, know I'm spending a couple of hours on this topic, but HTTPs will
>> slowdown my site forever.
> Measured in how much loss in performance? How loaded is the server? How
> many users do you have?
It sure will slowdown things.
I still have to do real world tests.
>>> heavier than nothing, probably true
>>> heavier than encrypting/decrypting all cookie values each time? slightly
>>> heavier timewise? not at all.
>> Encryption is not really needed, only signing.
>> But, as you say, HTTPs can be a better solution at all.
> signing is even heavier than encryption because signing means hashing
> and encrypting (a)symetrically which is what HTTPs does.
>> But I think that it will never be commited, since it will involve a
>> partial refactoring of Guard.
> A new guard version is already there
Where? The one in your sandbox?
> and we are about to start the
> biggest ticket in Nevow history... guard is not going to scare anyone
> (hopefully is going to go once web2 is finished).
So this means that the development of new guard is goind to happen in
Nevow and *then* ported to web2?
>> The same reason why old file upload support is still there (and there is
>> no control on the size of POST data so someone can send me an image of 3
>> At least I can change this without changing source code.
> Fixing this requires more than a simple refactoring... It's a complete
> overhaul of twisted.web API, which is twisted.web2.
But now twisted.web2 is not ready.
It will take an year to be usable in production.
I cannot tell Nevow to stop reading long POST data, but I can tell it to
do not parse this data.
As I can see, the big problem is with parsing.
>> I can create a session only to store some state (as an example, to count
>> how time an user failed the login).
>> Why it should have a guard attribute?
> Do you know that in python everything is by reference? It's not going to
> waste more time and having a reference to guard is useful for
> application level code that wants to mutate a session from
> unauthenticated to authenticated. (this is pretty much the only usecase).
You can need to initialize some state in your Session.
self.count = 0
sc = SessionManager.getSession(ICounter)
I can now use this simple session to limit logins attemps.
But I can bind the session to the source IP address, using this value as
(at least I would like to send an email to the site admin when having
100 logins attemps from the same IP address).
>> But you are also supposing that SessionManager creates only one king of
> I'm supposing that yes. Do you have a usecase besides the one already
> implemented in session.py where you have both persistent and non
> persistent sessions in the same object?
>>>> - If you choose to not create sessions for anonymous users, then there
>>>> is no more need for the loggedIn callback
>>> If you give me enough reason to remove the loggedIn callback I will
>>> remove it.
>> If it is possible to avoid creating sessions for anonymous users, then a
>> session needs only to be created after a successful login.
>> So you can put the code that is now in loggedIn in createSession.
> Which doesn't change the fact that createSession is not that easy to
> change while changing loggedIn just requires a subclass and override
> without even going for the upcall if you don't need to, because the
> callback is fairly easy (and that's why it's a callback).
This is true.
> 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.
But, if you say that sessions are *never* to be used except to hold
authenticated states (plus other persistent state, if one want to do
so), then... ok.
Regards Manlio Perillo
More information about the Twisted-web