Password policy
Password-based authentication flows are subject to frequent abuse through social engineering, password guessing and phishing
attacks. The Ory Network implements measures to provide high security for password-based flows. The Ory Password Policy follows
standards by the National Cyber Security Centre (NCSC)
and National Institute of Standards and Technology (NIST) as well as
leading security researchers.
Minimum password length
The password must by default at least be 8 characters long and all characters (unicode, ASCII) are allowed. Use the Ory CLI to change this value:
ory patch identity-config "$project_id" \
--replace '/selfservice/methods/password/enabled/config/min_password_length=12'
Similarity check
To prevent weak passwords Ory Identities implements different measures. Users often choose passwords similar to their traits (for
example the first name). To prevent this Ory Identities ensures there is a sufficient
Levenshtein-Distance (aka "Edit-Distance") between the identifier and the
password. For example if a users email is bob@example.com, bob24 would not be a valid password.
This feature is enabled by default. Use the Ory CLI to toggle it:
ory patch identity-config "$project_id" \
--replace '/selfservice/methods/password/enabled/config/identifier_similarity_check_enabled=false'
Leaked password check
Ory Identities checks passwords 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.
This feature is enabled by default. Use the Ory CLI to toggle it:
ory patch identity-config "$project_id" \
--replace '/selfservice/methods/password/enabled/config/haveibeenpwned_enabled=false'
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.
Custom User Interface
When using your own user interface, we recommend the following password policies to ensure security and good user experience:
- Allows the pasting of credentials in login etc. forms.
- Allow making the password visible through a modal.
- Don't show password hints to unauthenticated users.
- Don't expire passwords.
For a more detailed explanation of the concepts of these guidelines please visit the Security Profiles document.
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