[mod_python] Authentication and security in general

Dan Eloff dan.eloff at gmail.com
Tue Apr 25 18:37:59 EDT 2006

On 4/25/06, Deron Meranda <deron.meranda at gmail.com> wrote:
> On 4/25/06, Joshua Ginsberg <listspam at flowtheory.net> wrote:
> > > Surely it can't be all that easy? There must be some tricks for
> > > securing things that I'm not aware of. Something I'm misunderstanding?
> Proper website security is a very tough thing to get correct.
> The history is littered with big companies that have gotten it
> wrong: HotMail, Yahoo, Amazon, etc...  Fortunately for many
> sites just close enough is good enough.  You really need to
> determine what kind of security you need to figure out what to do.

Ironclad. I collect a lot of personal information about people
(including myself) and I don't want anybody else gaining access to

> Using cookies instead of (or in addition to) HTTP authentication
> (Basic/Digest) is in many cases somewhat better, mainly because
> you have better control over the browser memorizing passwords
> and that the server can make it easy to log off a user (just try to
> log off when using HTTP authentication).

Tell me about. I just implemented a mixed authentication system
yesterday (wrote my own impl of basic auth protocol, because an auth
handler wasn't working well for me) and was annoyed to discover that
even when I logout, the browser logs me right back in. I ditched that
now. I could have saved myself the trouble had I done my research
better to start with.

> If you want to do any sort of log off or expiration, you should also
> include the expiration date in the cookie content (and properly
> encrypted or signed), since the actual cookie expiration property
> is modifiable by the user.

How can anyone cause trouble like that? If a user goes to that much
bother to logout without being logged out, then he deserves to not be
logged out. Maybe on a shared computer it could be an issue, but you
shouldn't have a live session cookie on there anyway after your done
with it or you've got a security hole you could drive a tank through.

> And if not *everything* is over TLS/SSL, then it's not worth putting
> too much effort into it anyway.  (Which, btw, google mail can
> operate in all-SSL mode if you start at the page
> https://mail.google.com/ when you first log in).

Confirmed, I don't think I'd worry about that at home, but I'd
definitely use that feature on public networks.

>Even then though,
> if you're not validating client certificates, TLS/SSL is severely
> handicapped already from man-in-the-middle attacks.

I don't understand that could you please briefly explain it? Why am I
not validating client certificates and how do I do that?

> What I do (by using mod_python) is to use a cookie-based system.

Sounds very good actually.

Ok how's this for a design:

Login over https, send two cookies, each with a signed SID, one cookie
with secure enabled. Set the secure cookie with the path (say /secure)
where everything needs to be done with https.

If the unsecured cookie is present, and the SID checks out, and the
session is still valid, create the session (so basically the user is
logged in.) http is used preferentially after that. However any pages
where the user can access his information or do anything that you
wouldn't want someone else doing is in /secure and uses https. Mark
the session as 'secure' if the secured cookie is also present and the
SID checks out. Unless the session is marked secure for the /secure
directory, log them out and return them to the login screen. This
should be done in one place prior to handing off to a handler like you
did, so omitting it in a single handler doesn't create a security

One thing I'd love to know how to do though, is make sure all links
pointing to the /secure directory use https. I use purely relative
links inside my website because it makes moving code from development
server to production server and back really easy. Probably you could
do it with mod_rewrite.

Thanks for sharing your valuable input!


More information about the Mod_python mailing list