Skip to main content

v26.3.3

v26.3.3​

Kratos gains a FIPS 140-3 build with a PBKDF2 password hasher​

Ory Enterprise License releases now include a dedicated FIPS build of Kratos (kratos_oel_fips_<version>_<os>_<arch>) next to the standard build. The FIPS build uses the Go Cryptographic Module and starts with GODEBUG=fips140=on by default, so all cryptographic operations run through the FIPS 140-3 validated module. The standard build is unchanged.

PBKDF2 password hasher​

You can now choose pbkdf2 as the password hashing algorithm alongside argon2 and bcrypt. PBKDF2-HMAC-SHA256 is FIPS 140-3 approved, which makes it the recommended choice for FIPS-compliant deployments. Configure it under hashers:

hashers:
  algorithm: pbkdf2
  pbkdf2:
    iterations: 600000
    salt_length: 16
    key_length: 32

The defaults are 600,000 iterations, a 16-byte salt, and a 32-byte derived key.

Existing password hashes keep working​

Passwords hashed with a different algorithm still verify as before. When an identity signs in with such a password, Kratos re-hashes it with the configured algorithm on the next successful login, just as it already does when you switch between argon2 and bcrypt. No migration or password reset is needed.

FIPS mode log signals​

When the FIPS build runs, Kratos tells you where your configuration deviates from a FIPS-compliant setup:

  • On startup, Kratos logs that FIPS 140-3 mode is active.
  • On startup, Kratos warns when the configured password hasher or cipher is not FIPS 140-3 approved (any hasher other than pbkdf2, or any cipher other than aes, including the default noop).
  • When signing a session JSON Web Token through the JWT webhook, Kratos warns if the signing algorithm is not FIPS 140-3 approved (once per algorithm). Configure a JSON Web Key with an approved algorithm (RS*, PS*, ES*, HS*, or EdDSA) for a fully FIPS-compliant deployment.

These warnings do not block any operation.

One-time-code and verification messages can be branded per OAuth2 client​

The login_code_valid, registration_code_valid, and verification_code_valid courier templates (email and SMS), as well as the link method's verification_valid email template, now include a scoped oauth2_login_request object when the flow was started through an OAuth2 login challenge. Verification flows inherit the challenge from the OAuth2-initiated registration or login that triggered them. The object contains the challenge and the initiating client's client_id, client_name, client_uri, logo_uri, and metadata. Custom HTTP mail servers can brand these messages per OAuth2 client from template_data.oauth2_login_request.client — a trusted, server-sourced value — without relying on the end-user-controlled transient_payload or resolving the login challenge with an unscoped API token. Flows without a login challenge are unchanged.

Stricter validation of iOS device attestations at enrollment​

When you enroll an iOS device key, Kratos now inspects the authenticator data of the Apple App Attest attestation and rejects keys that fail any of these checks:

  • The attestation environment (AAGUID) must be the production environment. Development keys, which can be produced on jailbroken devices, are accepted only when relaxed attestation is enabled, and such keys remain short-lived.
  • The signature counter must be zero, confirming the key was just created and has never been used.
  • The credential ID embedded in the attestation must match the key identifier the client submits.

These checks harden the enrollment flow against forged or reused attestations. Compliant iOS clients are unaffected.