Skip to main content

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​

Password-based authentication flows are subject to frequent abuse through

  • Social Engineering Attacks;
  • Password Guessing Attacks;
  • Phishing Attacks.
info

Further improvements are work in progress and are tracked on GitHub.

Expensive hashing with BCrypt​

Ory Identities supports BCrypt for password hashing per default. BCrypt is recommended when you want hashing to take at most one second:

hashers:
  algorithm: bcrypt
  bcrypt:
    cost: 12

Expensive hashing with Argon2​

Ory Identities supports Argon2 for password hashing. Argon2 is recommended when you want hashing to take at least 2 seconds. You can tweak the Argon2 configuration in your Ory Identities configuration file:

hashers:
  algorithm: argon2
  argon2:
    memory: 128MB
    iterations: 2
    parallelism: 4
    salt_length: 16
    key_length: 32

To determine the ideal parameters, head over to the setup guide.

Password policy​

To prevent weak passwords Ory Identities implements different measures. Users often choose passwords similar to their traits. To prevent this Ory Identities ensures there is a sufficient Levenshtein-Distance (aka "Edit-Distance") between the identifier and the password. It also makes sure that the identifier and password have a small enough longest common substring.

Furthermore the password method comes with a build-in check against the "Have I been pwned" breach database. This way Ory Identities makes sure your users can't use passwords like "password", "123456" or any other commonly used one. To protect the value of the password the range API is being used.

Password policy best practices​

Almost every service with a login offers some type of registration using a password. Therefore, there are many strategies floating around, with many of them implementing terrible and insecure patterns such as:

  • Not allowing special characters in passwords.
  • Not allowing the use of password managers by disabling the "paste" functionality in password fields.
  • Requiring you to rotate your password every month (passwords expire).
  • ...

Troy Hunt has written an excellent piece on password policies and why they recently changed and how.

Ory Identities implements a password policy that:

  • Checks if a password has previously been leaked using the HIBP API,
  • Checks if a password is too similar to one of the identifiers,
  • Doesn't expire passwords.

This is a rundown of all the practices Ory Identities implements and why. Some things need to be implemented by yourself as they must be implemented in the User Interface that interfaces with Ory Identities. You can find these in the User Interface Guidelines section.

Password complexity​

This outline and quotes are defined in the NIST Digital Identity Guidelines - 5.1.1.2 Memorized Secret Verifiers. Ory Identities, unless explicitly advertised, implements these guidelines and best practices.

Passwords must have a minimum length of 8 characters and all characters (unicode, ASCII) must be allowed:

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

Passwords must be checked against a database of compromised secrets such as Have I Been Pwnd:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but isn't limited to:

  • Passwords obtained from previous breach corpuses.
  • Dictionary words.
  • Repetitive or sequential characters (such as ‘aaaaaa’, ‘1234abcd’).
  • Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

Don't require mixtures of characters types or prohibiting repeated characters:

Verifiers SHOULD NOT impose other composition rules (such as, requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

User interface guidelines​

These best practices need to be implemented in your User Interface and can't be handled by Ory Identities. All Ory-built reference and demo applications implement these best practices:

Allow pasting of passwords:

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

Allow the user to show the secret in the UI:

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it's entered. This allows the claimant to verify their entry if they're in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

Password hints​

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that's accessible to an unauthenticated claimant.

NIST Digital Identity Guidelines - 5.1.1.2 Memorized Secret Verifiers

Password expiry​

Forcing password expiry carries no real benefits because:

  • the user is likely to choose new passwords that are only minor variations of the old
  • stolen passwords are generally exploited immediately
  • resetting the password gives you no information about whether a compromise has occurred
  • an attacker with access to the account will probably also receive the request to reset the password
  • if compromised via insecure storage, the attacker will be able to find the new password in the same place

NSCS Password administration for system owners

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