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

Manlio Perillo manlio_perillo at libero.it
Thu Aug 3 11:28:04 CDT 2006

Valentino Volonghi aka Dialtone ha scritto:
> On Thu, 03 Aug 2006 12:17:03 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
> [...]
>>> Line 19:
>>> The most secure way is to use HTTPS, based on SSL. But SSL can cause
>>> too burden on an application.
>>> The most secure way to do what?
>> To use sessions.
> I think you are confused here... HTTPS and sessions are 2 totally
> different things.

Of course.

Is this better?:
"""Session cookies carry some text used to authenticate users (called

The only secure way to transport such an information beetwen client and
server is with HTTPS."""

> [...]
>> The system should ask for the user password when the user wants to
>> change its email address.
>> This is important *if* the system allow an user to ask for its forgotten
>> password and this is sent to its email address.
>> An attacker (that obtained a valid session ID) can change the account
>> email address and ask for the password!
> 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.

And now the attacker knows the username + password for a poor client.
And maybe this poor (and fool) client uses the same credentials for its
e-banking account...

>>> Session section:
>>> Why is it suggested to use cookies when at the end of the same
>>> subsection you say that this approach has several flaws?
>> Because, by design, sessions are not good for authentication.
> sessions are not authentication, of course they are not good for that.

Yes, sessions carry authenticators.

>> However cookies based sessions are better that URL based sessions or
>> form based sessions.
> They are different kind of things. 

Both cookies, URLs and hidden form's controls are a mean to transport
sessions IDs.

I'm just using sessions where I should say session IDs.

> Sometimes clients don't support
> cookies. How are you going to provide a usable website for them?

Do you prefer a fully usable site to a secure one?
Cookies are standards.

>> The only flaw of a well written session management system (as I can
>> understand) is a replication attack (done by someone that can see the
>> traffic beetwen client and server).
> Just use HTTPS.

I don't have an e-commerce site.
Its only a portal.

>> This assuming that one isn't using permanent sessions.
> There is no such thing as permanent sessions. They might be persistent
> for some time but not permanent.

Mea culpa on using the wrong term. Of course I intended persistent.

> [...]
> Much of the problems you are trying to find here are all resolved by
> using https for everything in your website. I doubt it's worth to lose
> so much developer time in trying to make secure something that cannot be
> secure by design (there is a machine that is not under your control and
> that is also the one you want to protect). Just use HTTPS for all your
> website. Safer and simpler.

I will do some test but HTTPs for every page is likely too heavy for the
poor server.

>> No.
>> I can create a complete "static" site, with all Resources created at
>> start time.
> You can do _EXACTLY_ the same thing with guard. Did I mention that guard
> is like it is to avoid changing ANY code in your application?
>> Maybe I need to add some examples.
>> And I would like to do some benchmark to understand the cost of creating
>> every resource object on the fly.
> rend.Page() objects are made to be destroyed for every request. 

Not sure.
The root resource is created only once, right?
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)

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

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


> [...]

>> This allow one to write custom code, as an example one can create an
>> additional cookie with a signed and crypted client address, using the
>> same interface.
>> Or, more paranoic, one can create an additional cookie with a signed and
>> maybe encrypted serial number.
>> This number is incremented at every request (both on the session cookie
>> and on the session object) and checked.
> This looks so paranoid 

Just as I have said.

> I can't believe anyone could use it... Why should
> I need such a secure way of communicating through the web? 

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

> there are
> already other kinds of mechanism that are even more secure than that. I
> think HTTPS, secure cookies and encrypted cookie values are more than
> enough to barely trust a cookie.
> Anyway it seems reasonable to factor out the cookie handling stuff.


Some other personal advice about yout guard implementation:
- I think that SessionManager should be renamed SessionFactory
- Maybe the getSession() of the SessionManager class should be changed
  in getSession(sessionInterface=ISession)
  That is, ISessionManager should work a little like the

  I can define an IGuardSession with additional features (the guard
  attribute that really make sense only for authenticator's sessions.)
- If you choose to not create sessions for anonymous users, then there
  is no more need for the loggedIn callback

A last thing:
how will be the Session management in web2?

You may wonder why I'm so paranoic.
Well, I'm reading

Thanks and regards  Manlio Perillo

More information about the Twisted-web mailing list