Password expiration presets should be in DAYS

[tomhundt]

Overview

The time interval presets available on the dropdown menu (to the right of the Expires datetime field) are currently as follows: {1, 2, 3} weeks, {1, 3, 6} months, or {1, 2, 3} years. Furthermore, they don't seem to be configurable.

This is not really useful, because mandatory password change times are usually given in numbers of days, and while a week always has seven days, a month can have from 28-31 and a year 365-366. Thus, these units are too imprecise.

Here's a quick survey of password expiry requirements:

Microsoft

For decades, the baseline password practices Microsoft provided to customers suggested forcing employees to change their passwords every 60 days.

The password reset timer in Windows Server products is still 42 days.

(source)

Okta

Single sign on (SSO) provider Okta uses 120 days as the default (source)

You can configure this setting for 1–999 days. (source)

(Okta also has a minimum required duration, before which the password cannot be changed. This is given in hours or days. This is to prevent a user from changing their password back to an old one.)

RedHat

RedHat's LDAP admin documentation says they do something similar to Okta, providing parameters

--maxlife [...] The default value is 90 days. --minlife [...] The default value is one hour.

Feature Requests

• Please let us specify the expiration in number of days from now.
• Please let us modify the presets, ideally on a site by site basis, since everybody has a different default. (I find myself writing this info in the notes field, along with the password requirements.)
• Perhaps the date picker could have a field or mouseover that tells us how many days we are in the future?
• Please let us have a notification when one is about to expire (this, of course, requires a threshold value, a "time to expiration"). Notification is not needed for every entry, but probably only one or two critical ones. (Inevitably, the same organizations requiring periodic changes are going to make it tedious to recover from missing one!) Currently, I put an alarm in my calendar for this.

Other Implementations

• Here is what Keepass has done.
• LastPass, sounds like they haven't done anything yet.
• PwSafe calls it recurring password expiration.

[droidmonkey]

What about something like this:

[Adriano-Baldi]

Great. You are doing a wonderful job! I am also very interested in a function that allows you to alert the user about passwords that are about to expire. On the old version of Keepass if I remember correctly, a warning appeared when opening the database. One idea could be a red flag in the top bar by pressing which highlights the expiring passwords.

[tunbridgep]

In addition, changing a password entry should reset it's expiration date automatically to the preset value, since changing a password in the real world also usually resets the expiry.

[droidmonkey]

Tracked by a different request and has a draft PR for that as well.

[pandruszkow]

Are there still plans to implement this feature? I'm especially interested in customisable expiration presets.

[Efus10n]

I'm also wondering if this is still being tracked. I would really like to be able to stop googling "today plus 60 days" and "today plus 90 days" so many times every month. I have a lot of accounts that use 60 and 90 day expirations but I can see where many users would have other policies so customizable input is probably best.

[JohnLGalt]

According to the notes above, in Milestone 2.7.1, the 12 hour expiration was merged into code on March 31. This particular issue (allowing for a fully modular numerical value and unit selection) was moved from 2.7.1 to 2.7.2 In April, and now has been moved to 2.8.0 as of last month, so yeah, they are still planning to implement, it's just been pushed back a little bit.

[zellerc]

What are the plans for this implementation or is it done already?

I also have that issue that i have "unusual" cycles like "42 days" to change my password.