Project

General

Profile

Feature #40329

mgr/dashboard: It should be possible to set an expiration date for the user password

Added by Tiago Melo 2 months ago. Updated 6 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
dashboard/usermgmt
Target version:
Start date:
07/18/2019
Due date:
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

As as admin I should be able to set a TTL for the password to expire.
It should be a cluster wide configuration.
p.e.: every user should change his password every 3 months.


Subtasks

Feature #40814: mgr/dashboard: Allow to set individual password expiry datesNew

Feature #40816: mgr/dashboard: Recalculate password expiry dateNew


Related issues

Related to mgr - Feature #40248: mgr/dashboard: As a user, I want to change my password Resolved 06/10/2019
Related to mgr - Feature #25229: mgr/dashboard: Provide user enable/disable capability Resolved 08/02/2018
Related to mgr - Feature #24655: mgr/dashboard: Enforce password change upon first login Need Review 06/25/2018
Related to mgr - Feature #25232: mgr/dashboard: Support minimum password complexity rules Need Review 08/02/2018
Related to mgr - Feature #39999: mgr/dashboard: Prevent brute-force/dictionary attacks against existing local user accounts New 05/22/2019
Related to mgr - Fix #40328: mgr/dashboard: Permanent notifications instead of repeated notifications Need Review 06/13/2019

History

#1 Updated by Tatjana Dehler about 2 months ago

  • Assignee set to Tatjana Dehler

#2 Updated by Tatjana Dehler about 2 months ago

  • Description updated (diff)

My current idea:

  1. How to configure the expiration date (admin perspective)
    A new setting USER_PWD_EXPIRY_SPAN will be added to settings.py. By default the value will be set to 0, which means the user passwords are never going to expire. The admin can configure this setting on command line (as a first step, would be great to integrate it into a configuration page at a later point of time) and set the amount of days to expire the password.
  2. How to check if the password is expired (internal implementation)
    A new attribute lastPwdUpdate (unix timestamp) will be added to the user class in access_control.py. When a user logs in and the USER_PWD_EXPIRY_SPAN is defined, the current time will be compared with the lastPwdUpdate value. If (current_time - lastPwdUpdate) < USER_PWD_EXPIRY_SPAN nothing happens. If (current_time - lastPwdUpdate) >= USER_PWD_EXPIRY_SPAN the user will be asked to set a new password. After that lastPwdUpdate will be set to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here.
  3. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Any further ideas/comments?

#3 Updated by Ricardo Dias about 2 months ago

Tatjana Dehler wrote:

My current idea:

  1. How to configure the expiration date (admin perspective)
    A new setting USER_PWD_EXPIRY_SPAN will be added to settings.py. By default the value will be set to None, which means the user passwords are never going to expire. The admin can configure this setting on command line (as a first step, would be great to integrate it into a configuration page at a later point of time) and set the amount of days to expire the password.

This means that the expiration span will be the same for all users. I'm not sure about the requirements for this feature, but we could easily define a different expiration span for each user by using a "pwdExpirySpan" attribute in the user profile. We could still have a USER_PWD_DEFAULT_EXPIRY_SPAN as a default value, if the admin wants the same for every user.

  1. How to check if the password is expired (internal implementation)
    A new attribute lastPwdUpdate (unix timestamp) will be added to the user class in access_control.py. When a user logs in and the USER_PWD_EXPIRY_SPAN is defined, the current time will be compared with the lastPwdUpdate value. If (current_time - lastPwdUpdate) < USER_PWD_EXPIRY_SPAN nothing happens.

I would use a "pwdExpirationDate" that would be set upon password change, and this allows to do a simpler comparison on login: _current_time < pwdExpirationDate

If (current_time - lastPwdUpdate) >= USER_PWD_EXPIRY_SPAN the user will be asked to set a new password. After that lastPwdUpdate will be set to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here.

I think we cannot request the user to change the password when the password expires because of security implications. Imagine the case of an attack that steals a list of active passwords. Then if the user did not change the password before the expiration data, the attacker can do the login in the system with the expired password, and the system will allow the attacker to change the password.

I think the correct approach here is to lock down the account when the password expires. Therefore the user should change the password before the current password expires.
If the user does not change the password in time, it must request the Administrator to enable the account with a new password.

  1. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Any further ideas/comments?

I think we should issue a warning upon login a few (configurable) days before the password expires so that the user has the time to change the password.

Also, this feature can only be implemented after https://tracker.ceph.com/issues/40248 is resolved, otherwise users will not be able to change their passwords.

#4 Updated by Patrick Seidensal about 2 months ago

Ricardo Dias wrote:

Tatjana Dehler wrote:

My current idea:

  1. How to configure the expiration date (admin perspective)
    A new setting USER_PWD_EXPIRY_SPAN will be added to settings.py. By default the value will be set to None, which means the user passwords are never going to expire. The admin can configure this setting on command line (as a first step, would be great to integrate it into a configuration page at a later point of time) and set the amount of days to expire the password.

This means that the expiration span will be the same for all users. I'm not sure about the requirements for this feature, but we could easily define a different expiration span for each user by using a "pwdExpirySpan" attribute in the user profile. We could still have a USER_PWD_DEFAULT_EXPIRY_SPAN as a default value, if the admin wants the same for every user.

I cannot think of a scenario where some users need to change their passwords more frequently than others. I'd postpone this implementation until it's actually required or at least clear, that some customers require such a feature.

  1. How to check if the password is expired (internal implementation)
    A new attribute lastPwdUpdate (unix timestamp) will be added to the user class in access_control.py. When a user logs in and the USER_PWD_EXPIRY_SPAN is defined, the current time will be compared with the lastPwdUpdate value. If (current_time - lastPwdUpdate) < USER_PWD_EXPIRY_SPAN nothing happens.

I would use a "pwdExpirationDate" that would be set upon password change, and this allows to do a simpler comparison on login: _current_time < pwdExpirationDate

If (current_time - lastPwdUpdate) >= USER_PWD_EXPIRY_SPAN the user will be asked to set a new password. After that lastPwdUpdate will be set to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here.

I think we cannot request the user to change the password when the password expires because of security implications. Imagine the case of an attack that steals a list of active passwords. Then if the user did not change the password before the expiration data, the attacker can do the login in the system with the expired password, and the system will allow the attacker to change the password.

I think the correct approach here is to lock down the account when the password expires. Therefore the user should change the password before the current password expires.
If the user does not change the password in time, it must request the Administrator to enable the account with a new password.

  1. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Any further ideas/comments?

I think we should issue a warning upon login a few (configurable) days before the password expires so that the user has the time to change the password.

Also, this feature can only be implemented after https://tracker.ceph.com/issues/40248 is resolved, otherwise users will not be able to change their passwords.

I like the rest of the proposal!

#5 Updated by Tatjana Dehler about 2 months ago

Ricardo Dias wrote:

Tatjana Dehler wrote:

My current idea:

  1. How to configure the expiration date (admin perspective)
    A new setting USER_PWD_EXPIRY_SPAN will be added to settings.py. By default the value will be set to None, which means the user passwords are never going to expire. The admin can configure this setting on command line (as a first step, would be great to integrate it into a configuration page at a later point of time) and set the amount of days to expire the password.

This means that the expiration span will be the same for all users. I'm not sure about the requirements for this feature, but we could easily define a different expiration span for each user by using a "pwdExpirySpan" attribute in the user profile. We could still have a USER_PWD_DEFAULT_EXPIRY_SPAN as a default value, if the admin wants the same for every user.

Yes, fine with me.

  1. How to check if the password is expired (internal implementation)
    A new attribute lastPwdUpdate (unix timestamp) will be added to the user class in access_control.py. When a user logs in and the USER_PWD_EXPIRY_SPAN is defined, the current time will be compared with the lastPwdUpdate value. If (current_time - lastPwdUpdate) < USER_PWD_EXPIRY_SPAN nothing happens.

I would use a "pwdExpirationDate" that would be set upon password change, and this allows to do a simpler comparison on login: _current_time < pwdExpirationDate

Also fine with me.

If (current_time - lastPwdUpdate) >= USER_PWD_EXPIRY_SPAN the user will be asked to set a new password. After that lastPwdUpdate will be set to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here.

I think we cannot request the user to change the password when the password expires because of security implications. Imagine the case of an attack that steals a list of active passwords. Then if the user did not change the password before the expiration data, the attacker can do the login in the system with the expired password, and the system will allow the attacker to change the password.

I think the correct approach here is to lock down the account when the password expires. Therefore the user should change the password before the current password expires.
If the user does not change the password in time, it must request the Administrator to enable the account with a new password.

Yes, I agree.

  1. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Any further ideas/comments?

I think we should issue a warning upon login a few (configurable) days before the password expires so that the user has the time to change the password.

Good idea!

Also, this feature can only be implemented after https://tracker.ceph.com/issues/40248 is resolved, otherwise users will not be able to change their passwords.

#6 Updated by Lenz Grimmer about 1 month ago

Thank you for this proposal and sorry for chiming in late here. The outcome of the conversation looks good to me (thanks to everyone who contributed), I'd like to point out one thing:

Tatjana Dehler wrote:

  1. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Due to security reasons, the dashboard must not reveal any specific details about why the user could not log in on the login page itself (at least not on the login page, adding a more detailed reason to the mgr log would be fine). An attacker should not get any hint about why the login failed, e.g. if the username or password were incorrect, or if the password expired. This would give them a clue on how to further proceed. For example: an error like "wrong password" would reveal to me, that the username was correct. Similarly, "password expired" would also reveal to me that the user account exists (and I could use social engineering to convince the admin to reset the password). As long as the password is still valid, it's of course fine to remind the user that their password is about to expire and should be renewed

Should we make it configurable how many days in advance this warning appears?

#7 Updated by Tatjana Dehler about 1 month ago

Lenz Grimmer wrote:

Thank you for this proposal and sorry for chiming in late here. The outcome of the conversation looks good to me (thanks to everyone who contributed), I'd like to point out one thing:

Tatjana Dehler wrote:

  1. How the user gets notified about it
    When a user tries to log in, he gets notified about the expired password on the login page. He'll be asked to set a new password which will also update the lastPasswordUpdate field to the current time. It would be great if the implementation of https://tracker.ceph.com/issues/24655 can used here as well.

Due to security reasons, the dashboard must not reveal any specific details about why the user could not log in on the login page itself (at least not on the login page, adding a more detailed reason to the mgr log would be fine). An attacker should not get any hint about why the login failed, e.g. if the username or password were incorrect, or if the password expired. This would give them a clue on how to further proceed. For example: an error like "wrong password" would reveal to me, that the username was correct. Similarly, "password expired" would also reveal to me that the user account exists (and I could use social engineering to convince the admin to reset the password). As long as the password is still valid, it's of course fine to remind the user that their password is about to expire and should be renewed

Yes, makes sense to me.

Should we make it configurable how many days in advance this warning appears?

Yes, that shouldn't be a problem.

#8 Updated by Lenz Grimmer about 1 month ago

  • Tags set to security
  • Target version set to v15.0.0

#9 Updated by Lenz Grimmer about 1 month ago

  • Related to Feature #40248: mgr/dashboard: As a user, I want to change my password added

#10 Updated by Lenz Grimmer about 1 month ago

  • Related to Feature #25229: mgr/dashboard: Provide user enable/disable capability added

#11 Updated by Lenz Grimmer about 1 month ago

  • Related to Feature #24655: mgr/dashboard: Enforce password change upon first login added

#12 Updated by Lenz Grimmer about 1 month ago

  • Related to Feature #25232: mgr/dashboard: Support minimum password complexity rules added

#13 Updated by Lenz Grimmer about 1 month ago

  • Related to Feature #39999: mgr/dashboard: Prevent brute-force/dictionary attacks against existing local user accounts added

#14 Updated by Ricardo Marques 24 days ago

  • Related to Fix #40328: mgr/dashboard: Permanent notifications instead of repeated notifications added

#15 Updated by Tatjana Dehler 6 days ago

  • Assignee deleted (Tatjana Dehler)

Also available in: Atom PDF