Hi Gunnstein, > I have attached a little specification of some new password handling > features: - password validation constraints > - password expiration
Please find attached my contribution to your specification. There is some extras for logging, update and lifetime. > I'd like to know if some or all of this has allready been implemented, > and if the author is willing to share? We are implementing this *now*, and we want to (must?) share it. Best regards, -- Christophe Condomines Director Software +34 680 661 144 --------------------------------- Microblau Serveis integrat d'informà tica empresarial --------------------------------- www.microblau.net | 93 726 41 99 Assistència internet: 902 075 006
SPECIFICATION FOR PASSWORD EXPIRY AND VALIDATION ------------------------------------------------ Gunnstein Lye <[EMAIL PROTECTED]> 3.12.2007 v.0.2 A specification for added and improved password features: - password validation constraints - password expiration 1. Password validation constraints A password MUST contain: - at least one* letter a-z or A-Z - at least one* number 0-9 *) The count MAY be made configurable, but this is not required. The password length MUST be greater than or equal to site.ini [UserSettings] MinPasswordLength (Not a new feature, this is standard.) The password MAY contain other characters, including but not limited to Japanese, IF site.ini [UserSettings] UseSpecialCharacters=true (Not a new feature, this is standard.) 2. Password expiration Passwords MUST have a limited lifetime. The length of the lifetime MUST be configurable. The system MUST accept 0 (zero) as a valid lifetime length, and MUST interpret this to mean no limit (infinite lifetime). At a set time before the password expires, the system MUST send an email to the user, stating that the password is about to expire. The time MUST be configurable. The text of the email MUST be configurable (template). When the password expires, the system MUST NOT accept it for gaining access to any content or feature other than the form where the user enters the new password. The system MUST check that the new password is not the same as the old one. The new and the old passwords MUST be different. The system MUST keep a history of old passwords. This history MUST be personal (per user). New passwords MUST NOT be equal to any password in the history. The password history MUST use the same password storage format as the rest of the system (which by default saves a hash, not the clear text password). The length of the password history MUST be configurable. The system MUST accept 0 (zero) as a valid history length, and MUST interpret this to mean no limit (infinite history). The password expiration date MUST be accessible via the user object, so that a warning can be displayed in templates (f.ex. "Your password will expire in 10 days, please change it [LINK]") 2.1 First password/force expiration The system must be able to generate a password for a new user and set it as expired. This is to ensure that a newly created user will first of all change his password. 2.1.1 Update by administrator If an authorized administrator updates the password of a final user, this new password must be marked as expired too. As this, the user will be forced to change his password at the next connection. 2.2 Lifetime per user/per group The lifetime of the password should also be configurable at system, group and user level. For example, force the standard users to update their password each 3 month, the editors each month and the administrators never. 2.3 Logging All the updates for password must be logged in the audit logs. In this log the following information must appear (at least): date, account updated, who has updated the account. Also the actions of enabled or disabling an account must be logged. For example, if there is a maximum number of failed login and the user reach this maximum, the deactivation of this user account must be logged. And when an administrator set back to active this user account, we also log all the information: date, account activated, who has updated the account. 2.4 Details The checking of already used old password must be made not only when the password expires, but also when the user choose himself to change his password. And if a user choose to change his password, the expiration date of the account should be extended. 2.5 Forget password 2.5.1 Process simplification (like told by Xavier Dutoit) The user puts his email in /user/forgotpassword, and receives an email containing a link with an auto generated hash. Going to the linked page, the user must choose a new password. 2.5.2 Validity of this link The link auto generated and send by email must also have an expiration. By default, we propose 24 hours. If nobody uses this link after 24 hours it will not be valid anymore. 2.5.3 Multiple generation of the link If an user uses twice (or more) the /user/forgotpassword and so generates different links, only the last one should work. The old ones must be deleted or invalidated. 3. Configuration All settings MUST be editable in the admin interface. The standard INI settings editor is acceptable.
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
