On Tue, May 12, 2009 at 11:13 PM, Paul Johnston <p...@pajhome.org.uk> wrote: > I noticed that AuthTktCookiePlugin does not check the timestamp. This > is a problem actually, it makes the cookie a "password equivalent" and > negates most of the benefits of hashing the password. I realise apps > could check the timestamp themselves, but I doubt many do. What I'd > suggest is adding two configuration parameters to AuthTktCookiePlugin: > > Timeout - default 15 mins, if timestamp is older than this, cookie > is treated as invalid > ReissueTime - default 5 mins, if timestamp is older than this, a > new cookie is issued, with the current timestamp
From a usability point of view, I think rounding up considerably on numbers makes sense. Reissue is seamless, so it's not much of an issue, but except perhaps for credit card or bank sites anything less than an hour or two for timeout will be annoying. I'd be apt to do a full day. Pinging the server via Javascript mitigates this, but adds its own problems, and doesn't help when you put your computer to sleep. > While this arrangement is not perfect, it's quite simple and solves > the main problem. I will produce a patch for this at some point. > > I also noticed that repoze.who does not do lockouts. Usually I > recommend that if there are three incorrect logins that the account is > locked for one hour. Again, this isn't perfect, but it's simple and > solves the main problems. I'm not going to implement this myself, but > I think you should put it on your development plans (sorry if there's > already a ticket, I've not checked trac). Is the issue dictionary attacks? If that's the case, a one-minute lockout would serve the purpose, wouldn't it? Or progressively larger lockouts, but starting at one hour is again going to (rightfully, I think) piss people off. Obviously configurable, but I don't like bad defaults. > A few other minor things to consider: > > I suggest you include a warning in the docs not to use the include_ip > option on AuthTktCookiePlugin. I did some experiments a while ago and > found that around 3% of web users change IP address during a session. > So turning this on will cause problems. Yes, I always turned this off when using it. If I remember correctly the tkt cookie doesn't include the ip address in plaintext, which is problematic. It would add some increased security if you were able to see that the IP changed, and test if the change is acceptable (using the GeoIP library to see the new and old location, and acceptable changes should be regionally similar -- an IP should never switch from the US to Russia, for instance). > Add a StatefulAuthCookiePlugin, where the session is saved in a > database. This allows strong logout where the cookie is invalidated on > the server. > > The redirect after login does not check the referrer is on the same > site. While it's unlikely this could enable any practical attacks, > putting in a check would be good practice. A whitelist of allowed domain locations would be useful. > By default, passwords are stored in the database without a salt. Usual > practice is to use a salt, to make things harder for an attacker, just > in case your password database is captured. The scheme I favor is > storing hmac_sha1(hmac_sha1(master_salt, user_name), password). > master_salt is a per-site value. What is the advantage of "hmac_sha1(master_salt, user_name)" over "master_salt+username"? -- Ian Bicking | http://blog.ianbicking.org -- Ian Bicking | http://blog.ianbicking.org _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
