Forum OpenACS Q&A: Re: Interesting article on web based password protection
I think that issue was related to the caching of session keys and using the "back" button after someone logged out of the site to get back in as that user, which has since been resolved with the login pages. At least, that's the issue that I can recall.
I happened to use some web sites that enforce some of the more cumbersome password protection schemes (password history, password expiration, minimum length + uppercase + non-alphanumeric). All I can say is that it gets really annoying, and just forces you to make your password vunerable in another way (e.g. password retreival/reset mechanism).
Personally, I've found that I'm always using the "forgot my password" link and getting a new temporary password for sites like that. Then when I log and try to set one, it says I've already used those 10 different passwords this year so can I please make up another one, which I'll promptly forget, so that I can avoid the security risk of writing it on a post-it on my monitor, and just use the "forgot my password" link the next time I need to log in again.
In practice, I think the best way to do it is the following, which I think is what we have in OpenACS:
- If you forgot a password, you need to get answer a challenge question.
- If you provide the correct answer, your new randomly-generated password will be sent to your email address.
- After you log in, you can either keep your new, hard to remember, randomly generated password or you can change it back to something you are likely to remember.
The challenge question/answer is nice because it prevents a new password from being sent to a compromised email address. Another nice thing about the challenge answer is that usually, you can make it free-form into a standard (for you) pass-phrase, hard to crack but easy to for me to remember. Personally, I never provide the answer to the question that is asked (and whose answer could be easily-determined, such as mother's maiden name or favorite color).
One other thing that could be incorporated to cut down on brute-force attacks would be automatically diabling the account after the nth failure and asking them to send email to the admin for help. Also, password change should always ask for your current password, to prevent people from taking advantage of a compromised machine with the login cookie already set, which OpenACS already does as well.
The problem with challenge/response is an astoundingly low success rate for "normal users." Users generally can't make heads or tails of the challenge-response process, for several reasons I won't go in to. I want to share the following semi-informed opinions:
For most public web sites, where getting broad participation is critical and neither data theft nor impersonation is critical, challenge-response isn't worth it. It provides a modicum of security and causes many possible users either to give up or to ultimately need human intervention to recover a password (again, a point at which many instead silently give up.).
Without rigorous ssl and a configuration making it impossible to submit a password in the clear, challenge/response is almost worthless because everything can just be sniffed.
The modal activity after a random password reset is, I would wager money, to use the new password once and then forget or lose it. Better to just re-send the original password in most cases.
So I guess I'm lobbying for two basic modes - minimal security, where you log in in the clear and can get your password back with a click, and real, where you log in over ssl, your proposed password is vetted against a dictionary, passwords expire, etc. One of these days I'll submit a patch for a new admin setting that cleanly disables challenge-response and hides every vestige of it.