|
| 1 | +## v26.3.3 |
| 2 | + |
| 3 | +### Kratos gains a FIPS 140-3 build with a PBKDF2 password hasher |
| 4 | + |
| 5 | +Ory Enterprise License releases now include a dedicated FIPS build of Kratos (`kratos_oel_fips_<version>_<os>_<arch>`) next to the |
| 6 | +standard build. The FIPS build uses the Go Cryptographic Module and starts with `GODEBUG=fips140=on` by default, so all |
| 7 | +cryptographic operations run through the FIPS 140-3 validated module. The standard build is unchanged. |
| 8 | + |
| 9 | +#### PBKDF2 password hasher |
| 10 | + |
| 11 | +You can now choose `pbkdf2` as the password hashing algorithm alongside `argon2` and `bcrypt`. PBKDF2-HMAC-SHA256 is FIPS 140-3 |
| 12 | +approved, which makes it the recommended choice for FIPS-compliant deployments. Configure it under `hashers`: |
| 13 | + |
| 14 | +```yaml |
| 15 | +hashers: |
| 16 | + algorithm: pbkdf2 |
| 17 | + pbkdf2: |
| 18 | + iterations: 600000 |
| 19 | + salt_length: 16 |
| 20 | + key_length: 32 |
| 21 | +``` |
| 22 | +
|
| 23 | +The defaults are 600,000 iterations, a 16-byte salt, and a 32-byte derived key. |
| 24 | +
|
| 25 | +#### Existing password hashes keep working |
| 26 | +
|
| 27 | +Passwords hashed with a different algorithm still verify as before. When an identity signs in with such a password, Kratos |
| 28 | +re-hashes it with the configured algorithm on the next successful login, just as it already does when you switch between argon2 |
| 29 | +and bcrypt. No migration or password reset is needed. |
| 30 | +
|
| 31 | +#### FIPS mode log signals |
| 32 | +
|
| 33 | +When the FIPS build runs, Kratos tells you where your configuration deviates from a FIPS-compliant setup: |
| 34 | +
|
| 35 | +- On startup, Kratos logs that FIPS 140-3 mode is active. |
| 36 | +- On startup, Kratos warns when the configured password hasher or cipher is not FIPS 140-3 approved (any hasher other than |
| 37 | + `pbkdf2`, or any cipher other than `aes`, including the default `noop`). |
| 38 | +- When signing a session JSON Web Token through the JWT webhook, Kratos warns if the signing algorithm is not FIPS 140-3 approved |
| 39 | + (once per algorithm). Configure a JSON Web Key with an approved algorithm (`RS*`, `PS*`, `ES*`, `HS*`, or `EdDSA`) for a fully |
| 40 | + FIPS-compliant deployment. |
| 41 | + |
| 42 | +These warnings do not block any operation. |
| 43 | + |
| 44 | +### One-time-code and verification messages can be branded per OAuth2 client |
| 45 | + |
| 46 | +The `login_code_valid`, `registration_code_valid`, and `verification_code_valid` courier templates (email and SMS), as well as the |
| 47 | +link method's `verification_valid` email template, now include a scoped `oauth2_login_request` object when the flow was started |
| 48 | +through an OAuth2 login challenge. Verification flows inherit the challenge from the OAuth2-initiated registration or login that |
| 49 | +triggered them. The object contains the challenge and the initiating client's `client_id`, `client_name`, `client_uri`, |
| 50 | +`logo_uri`, and `metadata`. Custom HTTP mail servers can brand these messages per OAuth2 client from |
| 51 | +`template_data.oauth2_login_request.client` — a trusted, server-sourced value — without relying on the end-user-controlled |
| 52 | +`transient_payload` or resolving the login challenge with an unscoped API token. Flows without a login challenge are unchanged. |
| 53 | + |
| 54 | +### Stricter validation of iOS device attestations at enrollment |
| 55 | + |
| 56 | +When you enroll an iOS device key, Kratos now inspects the authenticator data of the Apple App Attest attestation and rejects keys |
| 57 | +that fail any of these checks: |
| 58 | + |
| 59 | +- The attestation environment (AAGUID) must be the production environment. Development keys, which can be produced on jailbroken |
| 60 | + devices, are accepted only when relaxed attestation is enabled, and such keys remain short-lived. |
| 61 | +- The signature counter must be zero, confirming the key was just created and has never been used. |
| 62 | +- The credential ID embedded in the attestation must match the key identifier the client submits. |
| 63 | + |
| 64 | +These checks harden the enrollment flow against forged or reused attestations. Compliant iOS clients are unaffected. |
0 commit comments