As one of the people most interested in these features (and one of the probable implementers), allow me to chime in here. Any password system implemented in OpenACS should provide for the automatic blocking of authentication attempts from one IP whenever too many failures have occurred. This protects the system from dictionary attacks on poorly chosen passwords. It seems to me that this feature should be applied to any authentication end-point, without regard to the underlying authority. Without this, the end-point could be used as a privileged proxy for launching dictionary-based attacks on a website. I think this point should clearly illustrate the need to implement some of the authentication features outside the authority and some inside the authority.
The last point should probably be systematically applied to the list of authentication features. Here is the current list of features we want to make sure OpenACS has/acquires:
- auto-block of IP (with auto-unblock after period of time) after too many password failures in too-short a period of time
- successful login re-sets timer?
- this feature should always be enabled but the number of failed logins, the time period over which they must occur to incur blocking, and the length of the blocking should be configurable
- watch out for web-crawlers? Worst case scenario: this feature prevents a site from being indexed. This should not be an issue as long as the login form is actually a
<form> with a real >button< for submission. Most crawlers won't submit <form>s under those circumstances.
- upon successful login, notify user of:
- last successful login attempt (date/IP/referer/user-agent)
- # of failed login attempts since last successful login
… thus helping users to become aware that their accounts are under constant attack by hackers and hopefully detect a successful attack on their account.
- password strength checking (might annoy users, hence the mitigations above)
- password aging & history (for preventing re-use)
- minimum password age (before user can change)
- maximum password age (sets next password-expiration date, see below)
- password-expiration date
- expiration requires change immediately upon next login
- auto-account disable after extended disuse
- add a grace-period parameter/feature so enabling this feature does not immediately lock-out any users
- This way, admins can spam everyone when the feature is enabled, telling them to login soon to prevent the account from being locked.
- maximum number of concurrent sessions with same account (limits damage if credentials are stolen or shared inappropriately)
- maximum session length (whether idle or not)?
They are listed in order of priority (most important first). I think the only feature listed above that might be currently provided is the last one. I'm not certain because it may be more of an idle timeout rather than an absolute maximum on session length. Its not a very important feature.
