Threat models and security profiles

danger

Please be aware that this chapter is still work in progress. Not all mitigation strategies have been implemented yet in Ory Identities!

Running any software that stores personal information exposes the developer/company to risks. Analyzing which threat agents pose a risk, understanding the possible motivations for an attack, or why an agent is a threat, knowing the attack surface, the likelihood, and the impact are important all aspects of a threat model.

This documentation can't substitute a thorough and serious threat model, yet it will provide some guidelines to help configure Ory Identities in a way that makes it best suited for any risk assessment.

Account enumeration attacks

danger

This feature is a work in progress and is tracked as kratos#133.

It doesn't yet work as documented!

"Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack. Description of the Issue"

Source

Considering the above, an example would be for example an adult website. A threat agent wants to blackmail a well known politician by checking if someone can sign up at that website using the well-known-politician@email.com email.

If the service responds with Sorry, that email is already signed up here. Did you try to log in instead?, the agent is able to proceed with some type of blackmail scheme.

OWASP defines several Black-Box tests that cover Account Enumeration Scenarios.

This attack usually makes only sense if an email address or a phone number is collected during registration. For chosen usernames, this attack is much more difficult, as the attacker has to know what usernames the victim is using.

There are three common ways an attacker can figure out if a user is signed up at a service:

• During login: "No user with this email address was found"
• During registration or email update: "A user with this email address exists already"
• During password reset: "No user with this email address was found"

To mitigate this attack, the following methods need to be deployed:

• The login form should return the same message regardless of whether the password is wrong or the email/username doesn't exist: "The provided credentials are invalid."
• The password reset form should always return a success message and send out an email. If the email address is registered, a normal password reset email is sent. If the email address isn't registered, an email is sent to the address indicating that no account is set up with that email address. This is helpful to users that have multiple email addresses and are using the wrong email address for the password reset.
• The registration form should also always return a success message and send out an email. If the email address isn't yet registered, a regular "account activation" email is sent out. If the email address is registered already, a email is sent out telling the user that the account is already set up, and link to the login screen.

info

If you wish to mitigate account enumeration attacks, it's important to note that you can't sign in users directly after sign up! Depending on the type of service you provide, you might not care about this specific attack in which case direct login after sign up would be ok.

Hash timing attack mitigation

A timing attack against password hashing looks as follows:

1. Login to an existing account and measure time which takes, depending on the hashing configuration, between 200ms and 2s;0
2. Try out other accounts such as alice@example.org. If the account doesn't exist, password hashing doesn't run, hence it takes much less time for the server to answer (< 100ms).

To protect against this attack, Ory Identities adds a configurable delay with standard deviation to login flows where the account doesn't exist.

Enabling account enumeration defenses

Assuming you wish to enable account enumeration defenses, you need to configure Ory Identities as follows:

• Collect one or more email addresses during sign up and enable email verification.
• Don't enable the session post-registration workflow.

selfservice:
  flows:
    verification:
      enabled: true

Defending Against Account Enumeration when using OpenID Connect

Scenario: In some cases you might want to use the email address returned by for example the GitHub profile to be added to your identity's account. You might also want to use it as an email + password identifier so that the identity is able to log in with a password as well. An attacker is able to exploit that by creating a social profile on another site (for example Google) and use the victims email address to set it up (this only works when the victim doesn't yet have an account with that email at Google). The attacker can then use that "spoofed" social profile to try and sign up with your Ory Identities installation. Because the victim's email address is already known to Ory Identities, the attacker might be able to observe the behavior (for example seeing an error page) and come to the conclusion that the victim already has an account at the website.

Mitigation: This attack surface is rather small and requires a lot of effort, including forging an for example Google profile, and can fail at several stages. To mitigate any chance of that happening, only accept email addresses that are marked as verified in your Jsonnet code:

contrib/quickstart/kratos/email-password/oidc.github.jsonnet

local claims = {
  email_verified: false
} + std.extVar('claims');

{
  identity: {
    traits: {
      // Allowing unverified email addresses enables account
      // enumeration attacks, if the value is used for
      // for example verification or as a password login identifier.
      //
      // Therefore we only return the email if it (a) exists and (b) is marked verified
      // by GitHub.
      [if "email_primary" in claims && claims.email_verified then "email" else null]: claims.email_primary,
    },
  },
}

Disabling account enumeration defenses

Enforcing email verification, which requires an email round trip and disrupts the sign up process, isn't always feasible. In these cases, you might want to disable account enumeration defenses.

If you enable the session post-registration workflow - signing the user in directly after registration - disables account enumeration defenses:

selfservice:
  flows:
    registration:
      after:
        password:
          - hook: session

Account Takeover Defenses

The Settings Flow implements account takeover defenses as it isn't possible to change the password without knowing the existing password. A good example of this flow is the GitHub sudo mode.

Passwords

Head over to the password policy page.

Anti-automation

danger

This feature is a work in progress and is tracked as kratos#138.

Actions that cause out-of-band communications, such as sending an activation link via email or an activation code via SMS, can be abused by automated systems. The goal of such an attack is to send out so many emails or SMS, that your reputation worsens (spam filters) or you're faced with massive costs (carrier fees).

CAPTCHA renders these attacks either very difficult or impossible. CAPTCHA will be required in the following scenarios:

• The user tries to register more than one account within 72 hours.
• The user failed provide valid credentials for the third time within 12 hours.
• The user tries to recover their account for the second time within 72 hours.

For integration guidelines, please check the individual flow's (registration, login, account recovery) integration documentation.

Bruteforce attacks

Will be addressed in a future release.

Phishing attacks

Will be addressed in a future release.

Social engineering attacks

Will be addressed in a future release.

SMS spoofing attacks

Will be addressed in a future release.

Account enumeration

danger

This feature is a work in progress and is tracked as kratos#133.

It doesn't yet work as documented!

Digital identity guidelines

There is no one standard to digital identity. Ory Identities follows emerging frameworks and guidelines such as: Digital Identity Guidelines established by the National Institute of Standards and Technology (NIST) (and a follow-up FAQ) .