| Info |
|---|
This article is added with Smart ID 23.10.2. |
Hashing of user passwords is performed using Argon2id as the default algorithm, with configurable parameters that include:
Better protection against GPU-based attacks.
No maximum password length, unlike BCrypt2a.
BCrypt2a is demoted to legacy status with verification only, no BCrypt2a hashes are stored.
Configurable CPU/memory usage.
| Note |
|---|
Password hashes stored directly in Smart ID Identity Manager for CoreObject users and internal users are affected by the changed default algorithm. |
Configure user password hashing
...
Customize Argon2id password hashing
Smart ID Identity
...
Manager uses Argon2id to hash user passwords, which provides higher resistance against GPU-based attacks by being memory-hard.
| Info |
|---|
Memory-hardness refers to the property that hashing a password will consistently demand a specific pre-defined quantity of memory. This memory requirement significantly limits the extent to which hash calculations can be concurrently processed on GPUs, devices that typically excel in such computational tasks. |
You can customize several algorithm parameters to balance security with resource consumption (CPU/memory). The default values are chosen based on the defaults of Spring-Security 5.8+ and recommendations by the Open Worldwide Application Security Project (OWASP), as of end of August 2023, with some differences
...
Threads/lanes used during a single hashing operation.
Servers should stick to a value of 1. For more information, see this post by Steve Thomas from OWASP. Furthermore, Spring-Security's underlying implementation in BouncyCastle is single-threaded, so higher values would only favor an attacker.
| Note |
|---|
Keep the default value. |
...
:
...
Higher values slow down the hashing/verification and increases the CPU usage.
...
| Note | |
|---|---|
If you adjust the parameters, only newly created password hashes are affected. Existing password hashes use the parameters that they were created with. To avoid having the system run out of memory or the CPU being overloaded, tune the settings for your hardware environment before going productive. For example, if the system has a lot of RAM but few CPU cores, you can increase the memory requirement while reducing iterations. OWASP provides several examples of settings that offer equivalent security while having different CPU- and memory-requirements. Even if most of the users in your Identity Manager service log in via other methods than username and password (for example, SAML or certificates), there can be internal users with username and password that may be used by external services to log into Identity Manager, for example, for callbacks. Expand | |
Configure
...
docker-based
...
deployment:
Open the following files:
docker\compose\identitymanager\admin\docker-compose.yml
docker\compose\identitymanager\operator\docker-compose.yml
docker\compose\identitymanager\tenant\docker-compose.yml
Define SYSTEM_PROPERTIES with the desired values in the
environmentsection of the files, for example:
| Code Block | |
|---|---|
environment:
- 'SYSTEM_PROPERTIES={
"argon2PwEncoderFactory.saltLength ": "16",
"argon2PwEncoderFactory.hashLength": "32",
"argon2PwEncoderFactory.parallelism": "1",
"argon2PwEncoderFactory.memory": "19456",
"argon2PwEncoderFactory.iterations": "4",
...other properties...
}'
...other env vars...Expand | |
Configure WAR file deployment:
Edit WEB-INF\classes\system.properties in your Identity Manager Admin, Operator, or Tenant web applications and set the desired values, for example:
| Code Block |
|---|
argon2PwEncoderFactory.saltLength = 16
argon2PwEncoderFactory.hashLength = 32
argon2PwEncoderFactory.parallelism = 1
argon2PwEncoderFactory.memory = 19456
argon2PwEncoderFactory.iterations = 4 |
Handle legacy hashes
...
BCrypt2a verification
Existing BCrypt2a password hashes can still be used for verification, but you must change the existing passwords to gain the benefits of Argon2id.
...
SHA-256 based password hash verification
| Warning |
|---|
Support for SHA-256 password hashes is being discontinued since it is not considered sufficiently secure anymore. SHA-256 itself is not considered broken (unlike SHA-1). However, digest-based algorithms do not lend themselves well to secure password hashing, thus Spring recommends adaptive one-way functions instead. |
Existing SHA-256 password hashes can still be used for verification, but it is recommended to change existing passwords that were hashed this way. Make sure that you run PRIME or Identity Manager 3.7 or later before changing.
PRIME 3.6.8 was the last version to create these hashes by default (via Spring 4's ShaPasswordEncoder with predefined rounds and an optional, fixed salt), before version 3.7 switched to BCrypt2. You can search for the hashes in the Identity Manager database by searching for hashes that are a 64-character hex-string instead of starting with $argon2id$ (for Argon2id) or $2a$ (for BCrypt2a). Search for the following:
Password column of the UserData table
StringValue column of Person_additionalFields table, where the Name is "PasswordHash"
...
Considerations for exported configurations
Importing an existing configuration .zip that contains internal users will overwrite password hashes, potentially with older, insecure hashes or newer, incompatible ones. Make sure to consider this when working with multiple different PRIME or Identity Manager versions and their configurations.
...
Additional information
| Expand | ||
|---|---|---|
| ||
|