Feature #40329
closedFeature #47765: mgr/dashboard: security improvements
mgr/dashboard: It should be possible to set an expiration date for the user password
Added by Tiago Melo almost 5 years ago. Updated about 3 years ago.
100%
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.
Further questions:
- admin password expiry: Should it be possible to set an expiry date for the admin password as well? Or only if there is at least another admin account? If it should not be possible to set expiry date prevent the user from doing so.
- disabled users password expiry: Should it be possible to set/have an expiry date for disabled users?
- 'ac_user_create_cmd' requires timestamp as 'pwd_expiry_date': The function (ac_user_create_cmd) to create a user on the command line requires a timestamp as 'pwd_expiry_date' at the moment. Do we want to keep it or change the behavior here?
- recalculate password expiry date: issue https://tracker.ceph.com/issues/40329 introduces a default expiry span (USER_PWD_DEFAULT_EXPIRY_SPAN) for the user passwords and adds a password expiry date field (pwd_expiry_date) to the User class. If the administrator edits the USER_PWD_DEFAULT_EXPIRY_SPAN variable the password expiry dates need to be re-calculated.
- update password expiry date (which is set manually): If the 'USER_PWD_DEFAULT_EXPIRY_SPAN' is set and the user changes the password, it's easy to update the expiry date to the next date. But what happens if 'USER_PWD_DEFAULT_EXPIRY_SPAN' is not set and the password expiry date was entered manually?
Files
Screenshot_2019-09-11_15-23-50.png (60 KB) Screenshot_2019-09-11_15-23-50.png | banner mock-up using toasty library | Tatjana Dehler, 09/11/2019 01:28 PM |
Updated by Tatjana Dehler almost 5 years ago
- Description updated (diff)
My current idea:
- 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. - 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. - 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?
Updated by Ricardo Dias almost 5 years ago
Tatjana Dehler wrote:
My current idea:
- 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.
- 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.
- 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.
Updated by Patrick Seidensal almost 5 years ago
Ricardo Dias wrote:
Tatjana Dehler wrote:
My current idea:
- 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.
- 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.
- 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!
Updated by Tatjana Dehler almost 5 years ago
Ricardo Dias wrote:
Tatjana Dehler wrote:
My current idea:
- 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.
- 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.
- 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.
Updated by Lenz Grimmer almost 5 years 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:
- 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?
Updated by Tatjana Dehler almost 5 years 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:
- 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.
Updated by Lenz Grimmer almost 5 years ago
- Translation missing: en.field_tag_list set to security
- Target version set to v15.0.0
Updated by Lenz Grimmer almost 5 years ago
- Related to Feature #40248: mgr/dashboard: As a user, I want to change my password added
Updated by Lenz Grimmer almost 5 years ago
- Related to Feature #25229: mgr/dashboard: Provide user enable/disable capability added
Updated by Lenz Grimmer almost 5 years ago
- Related to Feature #24655: mgr/dashboard: Enforce password change upon first login added
Updated by Lenz Grimmer almost 5 years ago
- Related to Feature #25232: mgr/dashboard: Support minimum password complexity rules added
Updated by Lenz Grimmer almost 5 years ago
- Related to Feature #39999: mgr/dashboard: Prevent brute-force/dictionary attacks against existing local user accounts added
Updated by Ricardo Marques almost 5 years ago
- Related to Bug #40328: mgr/dashboard: Permanent notifications instead of repeated notifications added
Updated by Tatjana Dehler over 4 years ago
Updated by Tatjana Dehler over 4 years ago
- Status changed from New to In Progress
- Pull request ID set to 30939
Updated by Tatjana Dehler over 4 years ago
Further questions:
- admin password expiry: Should it be possible to set an expiry date for the admin password as well? Or only if there is at least another admin account? If it should not be possible to set expiry date prevent the user from doing so.
Passwords of admin accounts should never expire in my opinion.
- disabled users password expiry: Should it be possible to set/have an expiry date for disabled users?
It should not be possible to set an expiry date for disabled users in my opinion. While disabling a user account the expiry date field should be cleared if set.
- 'ac_user_create_cmd' requires timestamp as 'pwd_expiry_date': The function (ac_user_create_cmd) to create a user on the command line requires a timestamp as 'pwd_expiry_date' at the moment. Do we want to keep it or change the behavior here?
?
- recalculate password expiry date: issue https://tracker.ceph.com/issues/40329 introduces a default expiry span (USER_PWD_DEFAULT_EXPIRY_SPAN) for the user passwords and adds a password expiry date field (pwd_expiry_date) to the User class. If the administrator edits the USER_PWD_DEFAULT_EXPIRY_SPAN variable the password expiry dates need to be re-calculated.
?
- update password expiry date (which is set manually): If the 'USER_PWD_DEFAULT_EXPIRY_SPAN' is set and the user changes the password, it's easy to update the expiry date to the next date. But what happens if 'USER_PWD_DEFAULT_EXPIRY_SPAN' is not set and the password expiry date was entered manually?
I would assume the password expiry date will be cleared.
Updated by Lenz Grimmer over 4 years ago
- Status changed from In Progress to Resolved
Updated by Kefu Chai over 4 years ago
- Related to Bug #43431: mgr/dashboard: test_create_with_default_expiration_date (tasks.mgr.dashboard.test_user.UserTest) added
Updated by Ernesto Puerta over 3 years ago
- Status changed from Resolved to Pending Backport
- Backport set to nautilus
Updated by Ernesto Puerta over 3 years ago
- Copied to Backport #46837: nautilus: mgr/dashboard: user management improvements (password change, password complexity, ...) added
Updated by Ernesto Puerta over 3 years ago
- Status changed from Pending Backport to Closed
- Backport deleted (
nautilus)
For clean/safe backport it requires more than 11 additionall PRs
Closing.
Updated by Ernesto Puerta about 3 years ago
- Project changed from mgr to Dashboard
- Category changed from 150 to Component - Users & Roles