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

Manlio Perillo manlio_perillo at libero.it
Fri Aug 4 03:19:04 CDT 2006

glyph at divmod.com ha scritto:
> On Tue, 01 Aug 2006 21:09:55 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> I have written a new chapter for authentication.
>> It is still a draft (as always), and don't forget that I'm not an expert.
> I've just had a few minutes to read your chapter.
> Unfortunately I feel like it documents things exactly backwards.

Not backwards, I have used a bottom up approach.

> If you have issues with guard's implementation strategy they should be
> dealt with in discussions of implementation, not by telling Nevow's
> users to ignore it.

I'm not saying to ignore it.
I'm documenting alternate solutions.

> Any discussion of authentication in Nevow should begin and end with
> guard, with perhaps a few footnotes about how one might deal with
> various security concerns.  cookies vs. hidden form fields vs. URL
> prefixes is not an application-level consideration.  Code examples
> should focus on how to _avoid_ polluting your application with
> dependencies on implementation details of your authentication mechanism.

Yes, I agree here.

> Even without talking about integrating with other protocols (which is a
> _key_ feature of Nevow, as it is the only "twisted native" templating
> framework), asking every developer to re-implement authentication and
> choose between different security models and security properties of
> cookies vs. HTTPS vs. Basic vs. Digest is a recipie for disaster.  

The security model is always the same.
It shold be (and documented) inside the SessionManager/CookieFactory.

> This
> is hard enough for guard to get right by itself.  It is nigh impossible
> to provide generic, protocol-level APIs and some light discussion of
> their security implications and still expect people to get it right on
> their own.

> The "dos and don'ts" paper you cited repeatedly points out that security
> systems should not be written by people who are not experienced at doing
> such things: 

Because people will try to send usernames in clear with cookies, forget
to use secure cookies when using HTTPs, use crypt instead of SHA1...

The guard security model is:
1) create "secure" IDs
2) don't forget to set the cookie to secure, when using HTTPs
3) use this ID to lookup into server side state
4) make sure to check for sessions lifetime on the server side, not only
   on the client

Of course 1) is only against prediction and brute force attacks.
It can do nothing against replication attacks, so developers should be
informed to use persistent cookie with cares (depends on what they have
to protect). Of course one can use HTTPs.

People have to think with their mind.
As an example now I'm using Nevow because I have a lot of benefic (most
of all the reuse my knowledge of Twisted).

If I find that Nevow is too heavy I will try:
1) a new templating sistem
2) Django (?)

Maybe future hardware will allow me to use HTTPs as default choice, and so.

But I have to understand this issues.

> the collective experience of the community needs to be
> brought to bear to get ONE authentication system and API right for Nevow.

I don't like into being forced into using only one solution, but I agree
that guard is worth of being used, *always*.

However we have a different vision of developers.
I thinks that people should be documented about all possible things:
they should be able to do the right thing (suitable for their application).

Some of you think that people should be protected like childrens, you
even want to hidden things if they are too "scary".

> Now, guard is not currently as pluggable as it could be, 

Is this an interface/design problem, or simply a lack of support?

> but developers
> should be strongly encouraged to write to its API so that when we _do_
> eventually start adding support for things like ActiveDirectory and
> OpenID, Nevow applications will generally work properly.


Thanks and regards  Manlio Perillo

More information about the Twisted-web mailing list