2016-05-31 22:00:59 +00:00
[[_password-policies]]
2016-05-17 14:28:54 +00:00
=== Password Policies
2017-02-15 15:13:31 +00:00
Each new realm created has no password policies associated with it. Users can have as short, as long, as complex,
2017-08-28 12:50:14 +00:00
as insecure a password, as they want. Simple settings are fine for development or learning {project_name},
but unacceptable in production environments. {project_name} has a rich set of password policies you can enable
2016-05-17 14:28:54 +00:00
through the Admin Console.
Click on the `Authentication` left menu item and go to the `Password Policy` tab. Choose the policy you want to add in the
2016-06-07 15:47:46 +00:00
right side drop down list box. This will add the policy in the table on the screen. Choose the parameters for the policy.
2016-05-17 14:28:54 +00:00
Hit the `Save` button to store your changes.
.Password Policy
2017-08-28 12:50:14 +00:00
image:{project_images}/password-policy.png[]
2016-05-17 14:28:54 +00:00
2017-02-15 15:13:31 +00:00
After saving your policy, user registration and the Update Password required action will enforce your new policy. An example of a user
failing the policy check:
2016-05-17 14:28:54 +00:00
.Failed Password Policy
2017-08-28 12:50:14 +00:00
image:{project_images}/failed-password-policy.png[]
2016-05-17 14:28:54 +00:00
2017-02-15 15:13:31 +00:00
If the password policy is updated, an Update Password action must be set for every user. An automatic trigger is scheduled as a future enhancement.
2016-05-17 14:28:54 +00:00
==== Password Policy Types
Here's an explanation of each policy type:
2017-08-28 12:50:14 +00:00
ifeval::[{project_community}==true]
2016-05-17 14:28:54 +00:00
HashAlgorithm::
2017-02-15 17:01:01 +00:00
Passwords are not stored as clear text. Instead they are hashed using standard hashing algorithms before they are stored or validated.
2017-08-28 12:50:14 +00:00
The only built-in and default algorithm available is PBKDF2. See the link:{developerguide_link}[{developerguide_name}]
2017-02-15 17:01:01 +00:00
on how to plug in your own algorithm. Note that if you do change the algorithm, password hashes will not change in storage until
2016-05-17 14:28:54 +00:00
the next time the user logs in.
2017-08-28 12:50:14 +00:00
endif::[]
ifeval::[{project_product}==true]
2016-12-01 22:17:15 +00:00
Hashing Algorithm::
2017-02-15 17:01:01 +00:00
Passwords are not stored as clear text. Instead they are hashed using standard hashing algorithms before they are stored or validated.
2017-05-22 09:17:20 +00:00
Supported values are pbkdf2, pbkdf2-sha256 and pbkdf2-sha512.
2017-08-28 12:50:14 +00:00
endif::[]
2016-12-01 22:17:15 +00:00
Hashing Iterations::
2017-02-15 17:01:01 +00:00
This value specifies the number of times a password will be hashed before it is stored or verified. The default value is 20,000.
This hashing is done in the rare case that a hacker gets access to your password database. Once they have access to the database,
2016-05-17 14:28:54 +00:00
they can reverse engineer user passwords.
2017-02-15 17:01:01 +00:00
The industry recommended value for this parameter changes every year as CPU power improves. A higher hashing iteration value takes more CPU power for hashing,
2019-01-23 18:17:17 +00:00
and can impact performance. You'll have to weigh what is more important to you: performance or protecting your passwords stores.
2017-02-15 17:01:01 +00:00
There may be more cost effective ways of protecting your password stores.
2016-05-17 14:28:54 +00:00
Digits::
2017-02-15 15:13:31 +00:00
The number of digits required to be in the password string.
2016-12-01 22:17:15 +00:00
Lowercase Characters::
2017-02-15 15:13:31 +00:00
The number of lower case letters required to be in the password string.
2016-12-01 22:17:15 +00:00
Uppercase Characters::
2017-02-15 15:13:31 +00:00
The number of upper case letters required to be in the password string.
2016-12-01 22:17:15 +00:00
Special Characters::
2017-02-15 15:13:31 +00:00
The number of special characters like '?!#%$' required to be in the password string.
2016-12-01 22:17:15 +00:00
Not Username::
2017-02-15 15:13:31 +00:00
When set, the password is not allowed to be the same as the username.
2016-12-01 22:17:15 +00:00
Regular Expression::
2017-02-15 15:13:31 +00:00
Define one or more Perl regular expression patterns that passwords must match.
2016-12-01 22:17:15 +00:00
Expire Password::
2017-02-15 15:13:31 +00:00
The number of days for which the password is valid. After the number of days has expired, the user is required to change their password.
2016-12-01 22:17:15 +00:00
Not Recently Used::
2017-02-15 17:01:01 +00:00
This policy saves a history of previous passwords. The number of old passwords stored is configurable. When a user changes their password
2017-02-15 15:13:31 +00:00
they cannot use any stored passwords.
2018-01-02 13:05:56 +00:00
Password Blacklist::
This policy checks if a given password is contained in a blacklist file, which is potentially a very large file.
Password blacklists are UTF-8 plain-text files with Unix line endings where every line represents a blacklisted password.
The file name of the blacklist file must be provided as the password policy value, e.g. `10_million_password_list_top_1000000.txt`.
Blacklist files are resolved against `${jboss.server.data.dir}/password-blacklists/` by default.
This path can be customized via the `keycloak.password.blacklists.path` system property,
or the `blacklistsPath` property of the `passwordBlacklist` policy SPI configuration.