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

Manlio Perillo manlio_perillo at libero.it
Thu Aug 3 13:26:13 CDT 2006


Valentino Volonghi aka Dialtone ha scritto:
> On Thu, 03 Aug 2006 18:28:04 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> Of course.
>>
>> Is this better?:
>> """Session cookies carry some text used to authenticate users (called
>> authenticator).
>>
>> The only secure way to transport such an information beetwen client and
>> server is with HTTPS."""
> 
> This is better. Although 'carry some text used to' is not that good,
> what would be good is to write that it carries _exactly_.
> 

Ok.

> [...]
>
>> An attacker "authenticate" into the application using a stealed cookie.
>> No one is changing/regenerating the password, the attacker only changes
>> the account email address and then ask the system to send the
>> "forgotten" password to the new (under its control) email address.
> 
>> It needs to execute HTTP commands, and the sessions does not change.
> 
> Given your other suggestions (one of them was store the hash of the
> password) how are you going to send the "forgotten" password? You don't
> even know it.
> 

Ok, so you where supposing this feature.
And, indeed, I think I'm going to hash the passwords.

> 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).


> Anyway these suggestions are more part of another chapter that could be
> titled: "Suggestions on safe web app design" rather than part of the
> authentication chapter.
> 
>>> sessions are not authentication, of course they are not good for that.
>>>
>>
>> Yes, sessions carry authenticators.
> 
> What are these and why?
> 

authenticator or authentication token.
On papers (like http://pdos.lcs.mit.edu/cookies/pubs/webauth:tr.pdf) and
the OWASPGuide they use this term.

>>> They are different kind of things.
>>
>> No.
>> Both cookies, URLs and hidden form's controls are a mean to transport
>> sessions IDs.
> 
> Those are _different_ means to transport session ID.
> 

Ok.

>> Do you prefer a fully usable site to a secure one?
>> Cookies are standards.
> 
> You still have to show me how it is not secure to use session IDs in the
> URL.

http://divmod.org/trac/ticket/1377

Try to add the icon for XHTML validation.
You will see your session id on the validator page, once you visit it.

Your site can include links for sponsors.
And these sponsor may be interested to steal user's data.

Not so many user will click on these links, but some will do it.


I have also request the ticket #1378
But I think this is more difficult to exploit, unless you don't filter
this kind of HTML code:

<html>
  <body>
    <p>Hello world
      <meta http-equiv="Set-Cookie"
            content="sessionid=1234; Expires=Friday, 01-Jan-2010
000:00:00 0GMT">
    </p>
  </body>
</html>


How many developers knows to remove meta tag in the body?



>> I don't have an e-commerce site.
>> Its only a portal.
> 
> You are spending more time here talking about how to make session id
> exchange more secure while you could have simply used https and that's all.
> Doesn't sound very efficient.
> 

Well, know I'm spending a couple of hours on this topic, but HTTPs will
slowdown my site forever.

>> Mea culpa on using the wrong term. Of course I intended persistent.
> 
> persistent sessions are yet another thing and the user asks for the
> explicitly by ticking 'remember me'.
> 

Of course.

>> I will do some test but HTTPs for every page is likely too heavy for the
>> poor server.
> 
> 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.

> [...]
> 
> See? You can decide it, although if you did this because it was an
> optimization you will regret doing it.
> 

Well, for some uses cases it can just work.

>>> And this
>>> will be enforced without the context. Also... Are you actually worrying
>>> about creating one object compared to the cost of rendering a dynamic
>>> page? (and locating it!)
>>
>> I have learned to not make pre-assumptions without doing some tests.
> 
> well... I did tests and I know what happens during page rendering and
> page lookup. For each rendering 6 to infinite contexts are instantiated.
> If you nest more than 5 fragments python reaches the infinite recursion
> limit (this number might vary, just to give you an example of how many
> objects are created during rendering). 

But this is a nightmare! ;-)
Have you done some tests with the new version context-less?

> You are removing a:
> dialtone at aiolia /Volumes/dati/Sviluppo/Divmod/branches % python -m
> timeit -s 'class Foo(object): pass' -c
> 'Foo()'                                         [17:31]
> 1000000 loops, best of 3: 1.62 usec per loop
> 
> 1.62 usec (on my ibook)
> 
> over something that is extremely more expensive per se (child lookup).
> 

But you forgot to include some time here...

>>> Of course there's nothing that prevents you to
>>> return always the same page object from guard.
>>>
>>>> And guard has some (avoidable) security problems, too...
>>>> It uses URLs based sessions without my permission.
>>>
>>> my who? user? developer?
>>>
>>
>> Developer.
> 
> Can't see that as such a big problem... But it should be configurable
> indeed, open a ticket.
> 

Done.

But I think that it will never be commited, since it will involve a
partial refactoring of Guard.

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
MB).

At least I can change this without changing source code.

> [...]

>> Some other personal advice about yout guard implementation:
>> - I think that SessionManager should be renamed SessionFactory
> 
> It's not a proper factory. SessionManager is a clean name, it manages
> lifetimes and creation/destruction. Exactly what a manager does.
> 

Ok.

>> - Maybe the getSession() of the SessionManager class should be changed
>>  in getSession(sessionInterface=ISession)
>>  That is, ISessionManager should work a little like the
>>  ICredentialsChecker.
>>
>>  I can define an IGuardSession with additional features (the guard
>>  attribute that really make sense only for authenticator's sessions.)
> 
> what's an authenticator's session? 

A session used for user's authentication.

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?

And, indeed, in newow.inevow are defined ISession and IGuardSession.

> This might be useful but seems like a
> lot of added complexity for a pretty small usecase. Remember sessions
> are an implementation detail not something that should be exposed to the
> user. I can't imagine a need for such a generic API.
> 

You are right.
But you are also supposing that SessionManager creates only one king of
session.

>> - 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.



Regards  Manlio Perillo



More information about the Twisted-web mailing list