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

[Valentino Volonghi aka Dialtone]

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

>> This is a non-problem with my guard. Asking authentication each time
>> invalidates the current session credentials (because you changed the
>> password in the database when you autogenerated a new one). To reach the
>> user pages again you'd have to know the autogenerated one. because the
>> one stored in the session is not valid anymore.
>>
>
>Not sure.
>
>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.

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.

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?

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

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

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

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

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

>Not sure.

I guarantee you!

>The root resource is created only once, right?

You decide it.

>And I can do:
>
>class ChildPage(rend.Page):
>	...
>
>class MainPage(rend.Page):
>	...
>
>
>
>root = MainPage()
>child = ChildPage()
>
>root.putChild('a', child)
>child.putChild('b', child)
>
>
>server = appserver.NevowSite(root)

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

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

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

>Some sites, as an example, bind cookies to user IP address (Yahoo, at
>least some years ago).

Which is not secure, I can fake it, I might be behind a NAT, I might steal the computer, I might use a computer from an internet cafe` used by someone else before me. How is this going to be more secure? HTTPS is enough.

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

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

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