Threat models and security profiles

Threat modeling is essential for securing a system like Ory Identities. This document provides guidelines for identifying and analyzing threats and implementing security measures for Ory Identities.

Working with and managing software that stores personal information carries risk. It's important to identify threats and understand the system's attack surface, the likelihood, and the impact of an attack.

Regarding Ory Identities, threats could include hackers or malicious insiders who may try to steal or manipulate personal information. To protect against these threats, it's important to implement appropriate security measures, such as strong authentication and access controls. Regular monitoring and quick response to security incidents are also crucial. When using Ory Network, defenses are provided as part of the platform's security infrastructure. For self-hosted instances of Ory Kratos Identity Server, reach out to Ory Support.

Digital identity guidelines

No universally accepted standard for digital identity exists.
Ory follows Digital Identity Guidelines established by the National Institute of Standards and Technology (NIST).
These guidelines are accompanied by a FAQ that provides answers to common questions.

Defenses against bots and automated attacks

Ory Network takes a proactive approach to combat bot and other automated attacks with bot detection and suspicious IP throttling. To detect bots and throttle suspicious IPs, Ory Network leverages the Cloudflare Web Application Firewall (WAF) and Cloudflare Bot Management services. These features are built into Ory Network and allow Ory to defend against automated threats without impacting the user experience.

When using Ory Network, these automated attack defenses are provided as part of the platform's security infrastructure. For self-hosted instances of Ory Kratos Identity Server, it's the responsibility of the administrator to implement and manage appropriate measures to maintain a secure environment. Reach out to Ory Support for help with this task.

Defenses against brute-force attacks

Ory Network rate limits requests to the public API endpoints, for example the login and registration endpoints, as part of the platform's security infrastructure.

On top of that, Ory Network and Ory Enterprise License deployments can throttle failed sign-in attempts per submitted identifier and per client IP with exponential backoff. There is no account lockout: an attacker who keeps failing keeps the delay at its maximum, and no delay exceeds exponential_backoff.max. Unknown identifiers are throttled like known ones, so the throttle reveals nothing about which accounts exist.

selfservice:
  flows:
    login:
      brute_force_protection:
        enabled: true
        identifier:
          max_failures: 6
          window: 5m
          exponential_backoff:
            initial: 1s
            max: 15m
        ip:
          max_failures: 51
          window: 1m
          exponential_backoff:
            initial: 1s
            max: 15m

Field	Meaning
enabled	Whether the throttle runs. Required. false keeps the values so the feature can be re-enabled.
max_failures	Failed attempts tolerated inside the window before delays start.
window	How long a count lives after its first failure. A delay extends it to the delay's end.
exponential_backoff.initial	The first delay once the threshold is exceeded. It doubles with every further failure.
exponential_backoff.max	The upper bound on the delay, at most 8760h (one year).

Nothing has a default. A listed key (identifier, ip) must carry all of its fields, and a key that is not listed is not throttled. The throttle applies to the password, code, and identifier_first methods. Sign-ins through a social provider or a passkey are not throttled; they submit no credential to guess. A successful sign-in does not reset the count; the window does.

Ory Kratos reads the client IP from the True-Client-IP, Cf-Connecting-IP, X-Real-IP, and X-Forwarded-For headers, in that order, before it falls back to the connection address. On Ory Network the edge sets these headers. When self-hosting, the reverse proxy in front of Ory Kratos must set them from the connection it accepted and drop any values the client sent.

API and native clients receive HTTP status 429 with error ID login_throttled and retry_after seconds in the error details. Browser flows are redirected to the error page, which shows the same error.

Configure brute-force protection on Ory Network

Brute-force protection is available on Ory Network Enterprise plans.

Ory Console

1. Go to Authentication → General in the Ory Console.
2. Toggle Brute-force protection. Throttling by identifier and by IP address starts with the values from the example above.
3. Change the values, or turn off Throttle by identifier or Throttle by IP address.
4. Click Save.

Ory CLI

ory patch identity-config --project <project-id> --workspace <workspace-id> \
  --add '/selfservice/flows/login/brute_force_protection={"enabled":true,"identifier":{"max_failures":6,"window":"5m","exponential_backoff":{"initial":"1s","max":"15m"}}}'

When self-hosting the open source Ory Kratos Identity Server, it's the responsibility of the administrator to implement and manage rate limiting or other measures to ensure the security of the network. Reach out to Ory Support for help with this task.

Defenses against cross-site request forgery

Cross-site request forgery (CSRF or XSRF) is an attack where a malicious site tricks a user's browser into sending a request to another site without user consent. This can occur even without a user session in a login CSRF attack. In the context of Ory Identities, it's an attack vector that can be exploited to gain unauthorized access to a user account or perform actions on their behalf.

To protect against these attacks, Ory Identities uses various countermeasures, including the sameSite attribute and a dedicated anti-CSRF cookie using the synchronizer token pattern. The protected APIs are mainly the endpoints that accept the POST, DELETE, or PUT methods. For example, when an app renders a form, a <input type="hidden" name="csrf_token" value="..."> HTML input element is added. Ory Identities compares that value to the value set in the anti-CSRF cookie. If the values match, the request is allowed.

Password policy

By default Ory uses a password policy that follows the Digital Identity Guidelines established by the National Institute of Standards and Technology (NIST). To learn more about configuring up a password policy, refer to the password policy page for instructions and best practices.

OAuth 2.0 security

Ory OAuth2 and OpenID Connect is a certified OAuth2 and OpenID Connect provider. You can read more in the OAuth 2.0 security overview documentation.

Filesystem sandbox

On Linux 5.13 and later, Ory Identities applies a Landlock filesystem sandbox to limit what the process can read or execute at runtime. Ory Network and OEL deployments sandbox the full kratos serve process; the OSS binary sandboxes the hidden Jsonnet worker so mapper code cannot reach the filesystem under any circumstances.