Configure user password hashing in Identity Manager

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.

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.

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:

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.

Configure docker-based deployment:

1. 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

2. Define SYSTEM_PROPERTIES with the desired values in the environment section of the files, for example:

    environment:
      - 'SYSTEM_PROPERTIES={
          "argon2PwEncoderFactory.saltLength ": "16",
          "argon2PwEncoderFactory.hashLength": "32",
          "argon2PwEncoderFactory.parallelism": "1",
          "argon2PwEncoderFactory.memory": "19456",
          "argon2PwEncoderFactory.iterations": "4",
...other properties...
        }'
...other env vars...

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:

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

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