Passwords¶
Changing and recovering passwords¶
The user may request to change their password, or may forget it and ask to have it reset.
To change password, the user must have the user/password
permission.
When the user requests a reset of a forgotten password, an email is sent to them with a token. It allows them to create a new password.
For information about how to create and configure the template, see Add forgot password option
The template for this email is located in Resources/views/forgot_password/mail/forgot_user_password.html.twig
in ibexa/user
.
You can customize it according to your needs.
The validity of the password recovery token can be set using the ibexa.system.<siteaccess>.security.token_interval_spec
parameter.
By default, it is set to PT1H
(one hour).
Revoking passwords¶
In case of a security situation such as a data leakage, you may need to force users to change their passwords.
You can do it with the help of the ibexa:user:expire-password
command,
which revokes the passwords for specific users, User Groups or users belonging to the chosen content type.
To select which users to revoke passwords for, use one of the following options with the command:
--user-id|-u
- the ID of the user. Accepts multiple user IDs--user-group-id|-ug
- the ID of the user group. Accepts multiple group IDs--user-content-type-identifier|-ct
- the identifier of the user content type. Accepts multiple content types
You can use the following additional options with the command:
--force|-f
- commits the change, otherwise the command only performs a dry run--iteration-count|-c
- defines how many users are fetched at once. Lowering this value helps with memory issues--password-ttl|-t
- number of days after which new passwords expire. Used when the command enables password expiration for user content types that do not use it yet.
For example, to revoke the passwords of all users of the user
content type, run:
1 |
|
To perform a dry run (without saving the results) of revoking passwords of all users from user group 13, run:
1 |
|
Password rules¶
You can customize the password policy in your project. Each password setting is customizable per User Field Type. You can change the password attributes or password expiration settings, and determine the rules for repeating passwords.
To access the password settings:
- In the Back Office, go to Content -> Content types.
- In the Content type groups table, click Users.
- Edit the User content type.
- In the Field definitions list, view the settings for User account (ezuser).
Tip
There can be other content types that function as users, beyond the built-in User content type. For details, see User Identifiers.
Password attributes¶
In the User account (ezuser) Field definition, you can determine if the password must contain at least:
- One uppercase letter
- One lowercase letter
- One number
- One non-alphanumeric character
You can also set the minimum password length.
Password expiration¶
In the User account (ezuser) Field definition, you can set password expiration rules, which forces users to change their passwords periodically.
You can also decide when the user is notified that they need to change their password. The notification is displayed in the Back Office after login and in the User content item's preview.
Repeating passwords¶
You can set a rule that the password cannot be reused. You set it for the User content type in the User account (ezuser) Field Type's settings. When this is set, the user cannot type in the same password when it expires. It has to be changed to a new one.
This only checks the new password against the current one. A password that has been used before can be used again.
This rule is valid by default when password expiration is set.
Breached passwords¶
You can set a rule that prevents using passwords which have been exposed in a public breach. To do this, in the User account (ezuser) Field definition, select "Password must not be contained in a public breach".
This rule checks the password against known password dumps by using the https://haveibeenpwned.com/ API. It does not check existing passwords, so it won't block login for anyone. It applies only to new passwords when users change them.
Note
The password itself isn't sent to the https://haveibeenpwned.com/ API, which makes this check secure. For more information on how that is possible, see Validating Leaked Passwords with k-Anonymity.