Forum OpenACS Development: User Password Management

Posted by Avni Khatri on
Hi -

We (MGH) are working with UCLA on some improvements to the Faculty Database / Profiles system they built on top of OpenACS. They have a new requirement to build in user password management (password expiration, max attempts lock) into OpenACS for a client of theirs and were wondering if anyone has done that and/or is considering doing it? If not - would it make sense to build these password management features into the core as optional features that administrators could enable?

Thanks much,

Posted by Dave Bauer on
This makes sense.

Originally I thought you could implement a separate authority, but that doens't make sense.

They should be parameters either for acs-authentication, or per-authority settings.

Overall they seem like good features. It probably would make sense to have a callback to allow extension of the password rules.

Posted by Andrew Helsley on

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:

  1. 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.
  2. 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.
  3. password strength checking (might annoy users, hence the mitigations above)
  4. 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
  5. 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.
  6. maximum number of concurrent sessions with same account (limits damage if credentials are stolen or shared inappropriately)
  7. 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.

Posted by Andrew Helsley on
Hmmm, under #2 I should add:
  • # of concurrent active sessions with option for user to terminate them.
and under #5 I should also add:
  • Implement as auto_disable_date and manual_disable_date columns. The manual date can be used to make temporary accounts without having to remember to go back and disable them.