Hi,
Ok, I've had a little look at how I could implement the JavaScript
hash login. I'll create a HashFormPlugin that is a challenger and an
identifier. As for the Authenticator, maybe I'll create a new
SQLHashAuthenticatorPlugin, or maybe I'll just provide a
default_hash_compare function to pass to SQLAuthenticatorPluig. (any
opinions from here welcome).
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
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).
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.
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.
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.
None of these issues are major, but if I was security testing an app
based on repoze.who, I'd flag them as low-risk issues. To be fair
though, I don't think anyone's been proposing using repoze.who to
protect the nuclear launch codes :-)
Ok, that's it for now, let me know what you think.
Paul
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
