[John Morton]
Harald Meland writes:
As the extra complexity added by having to save session state on the server side (i.e. have Mailman keep track of session IDs) is rather large, and as Mailman isn't safe from package sniffing anyway (unless you're running things on a SSL server, in which case cookie sniffing shouldn't be of any trouble anyway), I settled for slightly less.
True. Though stealing a cookie via packet sniffing will still require the thief to be on the same IP as the original cookie owner, or it will require them to fake their IP as well.
I wasn't really thinking of cookie stealing, but rather on plain text password sniffing... and to remove that vulnerability, one would have to use SSL or somesuch.
[Note, I'm not a python hacker, so bear with me :-) ]
Do add the domain that this mailman for this list is supposed to be under (or the browser will send this cookie to every site you connect to!)
RFC 2109 has this to say:
4.3 User Agent Role
4.3.1 Interpreting Set-Cookie
The user agent keeps separate track of state information that arrives
via Set-Cookie response headers from each origin server (as
distinguished by name or IP address and port). The user agent
applies these defaults for optional attributes that are missing:[...] Domain Defaults to the request-host. (Note that there is no dot at the beginning of request-host.)
... so I think that the current behaviour of not specifying the cookie's domain at all is correct.
and restrict the scripts that it is sent to to /mailman/ at worst, /mailman/admin and /mailman/admindb separately at best (allowing separate passwords for those two scripts is a needed feature for a proper distinction between list admins and moderators, anyway).
Current behaviour is to restrict to /mailman (well, the code is really using path part of mm_cfg.DEFAULT_URL) -- to allow the same cookie to authenticate against both admin and admindb pages.
If a separate admindb password is implemented, it won't be a problem to issue a cookie with a different name for authentication with that password (e.g. use the 'listname:admin' cookie for access to both admin and admindb, and also test for 'listname:admindb' if the first fails on admindb access).
I'd prefer to grab the secret from a file that's refreshed via a cronjob every 24hrs or so.
Uhm, then anyone getting their cookie just before the secret is refreshed will have to re-enter their password before their cookie should have expired. Do we really want that?
mac = hash(secret + client_ip + `issued` + `expires`)Is the hash() function one way?
Yup, at least for now (and I believe it wouldn't be of much use as a hashing function if it wasn't).
The FAQ talks about doing a second round of MD5 hashing to '...avoid an attack in which additional data is appended to the end of the cookie and a new hash recalculated by the attacker.', but I don't really understand why that's necessary.
Neither did I -- but I believe the FAQ answer made the assumption that the server stores more session state than Mailman does.
Should we check that expires - issued = mm_cfg.ADMIN_COOKIE_LIFE ?
Depends on whether you want cookies issued directly before the site admin changes ADMIN_COOKIE_LIFE to go dead immediately or not until after they were set to expire on creation.
The combination of a cryptographic hashing function and a secret key that's regenerated on a 24hour cycle makes an attack by constructing a cookie infeasible (at least, within the useful lifetime of whatever hashing function we're using).
I'm hoping that using the list's encrypted admin password as secret, in combination with a relatively short expire time, is sufficient -- but I'm no cryptography expert. I _am_ trying to keep the applied security mechanisms within reason, though -- if you want a completely bullet-proof Mailman, use an SSL-enabled server.
Remaining sources of attacks are:
Packet sniffing: They could steal the cookie this way. But they'd just steal the password, anyway, so it's a moot point. Use SSL if you're that paranoid.
Exactly.
Stealing the cookie: Presumably by some method other than packet sniffing or direct access to your terminal; maybe a broken browser could be distributing the cookie to every site it meets. The attacker will need to fake your IP to the web server _and_ get the response back, which is rather hard.
Hmmmm... how do proxies (e.g. web cache servers) enter into this picture?
Getting access to your terminal: The short expiry time is supposed to help defeat this problem.
I was wondering whether Mailman should re-issue a new cookie on each successful cookie authentication, but decided against it -- partly due to this possible problem, partly because it would annoy people who have their web browser warn them before accepting new cookies, and partly because anyone struggling with Mailman's web admin interface to a single list for more than (the default) three hours probably is such a humble person that having to enter the admin password once more won't be a big problem :)
The price to pay for the convenience of not having to type the password in every time.
Indeed.
Perhaps having an option to turn off the use of cookies will keep the paranoid happy and allow admins to use their servers native authentication methods. Perhaps modules to interface between mailman and the various different web servers is a direction someone would like to go in?
An option to disable cookie authentication altogether is easily implemented (have a look at SecurityManager.WebAuthenticate()) -- but I don't know anything about "native authentication methods", so I think I'll put it off until I understand the issues better.
Harald