Open patricknelson opened 6 years ago
tractorcow
commented
6 years ago Also how do you feel about a grace period, within which a user cannot login with their existing password, but they are still able to use their password to change to a new one? I.e. they can use the "enter old / new passwords and change it". That might promote better user retention and avoid users ignoring their expiration time.
patricknelson
commented
6 years ago No problem with that. I would add that as a separate option, however. The reason why:
Theoretically. There are some factors that could get in the way as well, e.g. the developer didn't properly configure email, the CMS admin enables password expiration on the system and locks themselves out and no longer has access to their original email account. Possibly edge case, but worth considering.
That reminds me: I should probably ensure in the RFC/Spec that enabling this option in the CMS should reset the PasswordAge value. What do you think?
Also, if this is done, should a warning be presented? e.g. "Enabling this option will lock users out of the system who have not changed their passwords within the specified time period. All users in the system will be required to update their password in [x] days starting from today."
kinglozzer
commented
6 years ago My gut instinct says that this is great, but probably belongs in a module. Itād also be a good test of how extensible our new authentication architecture is - I suspect that simply blocking login would be fairly simple, but adding an extra UI for the grace period suggestion might be a sterner test. We also need to ensure that this would only be enabled for password-based authenticators (obviously š)
Easily accessible option within the CMS accessible only to administrators (e.g. via SiteConfig)
Perhaps an extra tab in Security would be a more natural home? Not sure, Iād be happy either way.
- Adding a banner in the CMS to notify the user that their password will expire in [x] days.
- Enabling email notifications to users to notify them that their password will expire in [x] days.
Sounds good. Email notifications could be provided as a queuedjobs task, with queuedjobs being a composer suggested module
For CMS related login, I think it's reasonable to not allow for a grace period, because...
This hints at per-group configuration (unless you mean youād globally disallow grace periods for a site which doesnāt have āfront-endā logins). Not sure if thatās what you meant, but it might be worth considering...
There are some factors that could get in the way as well, e.g. the developer didn't properly configure email, the CMS admin enables password expiration on the system and locks themselves out and no longer has access to their original email account. Possibly edge case, but worth considering.
I donāt see these as major hurdles. Both scenarios can already happen without this feature, and thatās when they call us to rescue them š
Also, if this is done, should a warning be presented? e.g. "Enabling this option will lock users out of the system who have not changed their passwords within the specified time period. All users in the system will be required to update their password in [x] days starting from today."
If this is part of the UI in SiteConfig, I think that makes sense.
patricknelson
commented
6 years ago hints at per-group configuration
Actually I'm thinking it'd be exposed as a permission and then imputed directly via group or indirectly via role. But yeah, good point.
Introduction
When reviewing internal password policies, I noticed that we currently cannot natively impose any sort of password expiration on member accounts within SilverStripe.
NOTE: While it would be an interesting discussion, this RFC is not intended to dive into the advantages/disadvantages of actually having such password expiration policies. It's an additional feature (disabled by default) which would enable folks (especially corporate types š) to check off a box by making the option available to us. That would give SilverStripe an advantage in providing functionality for us "out of the box".
Proposal
Allow the ability to enable password expiration via:
If enabled, users would be required to change their passwords according to the specified schedule or be prevented from logging in until they change their password again. Other policies already in effect in the CMS will already ensure that previous passwords cannot be reused and must match various strength criteria.
Implementation
Retention and format:
Site Configuration:
Regardless of which approach is used to enable the feature, it can be retained as a single integer representing the number of days upon which a password can be expired. Specifically:
=0: No expiration imposed.>0: Passwords at or order than this amount must be changed.Password Age (Per User):
An additional column could be added to the
Membersretaining the UTC date timestamp of the last time the user's password was changed. This field could be calledPasswordAgeand would be set when the user's account was created, reset by an admin or reset by the user themselves.Enforcement:
Initially this can be enforced at login. If the user's password is older than the defined amount of days, the user would no longer be allowed to login. To regain access, they must proceed to reset their password using the standard means.
NOTE: See below under "Other considerations" to help prevent getting to this stage for most normal and active user accounts.
Impact
Compatibility
Initially for backward compatibility we should default password expiration to false and allow for the developer to enable this feature. However, ideally this feature would be enabled by default or at least easily enabled by a CMS administrator in a central location.
User Awareness
When requiring users to keep their passwords up to date, it's best to ensure they're properly informed. This could be performed various ways:
[x]days.[x]days.