Some time ago I was looking for the current password security standards to design a good and safe solution according to nowadays recommendations. I was very surprised, that some of them are in conflict with each other. That’s why I decided to prepare a short summary of password security standards from the most popular global standards.

There are presented the following standards: OWASP, OWASP ASVS, NIST, PCI-DSS and ISO 27001 with my comments.

OWASP

• Do do not truncate passwords. Make sure that every character the user types in is actually included in the password.
• Password must meet at least 3 out of the following 4 complexity rules
  • at least 1 uppercase character (A-Z)
  • at least 1 lowercase character (a-z)
  • at least 1 digit (0-9)
  • at least 1 special character(punctuation) — do not forget to treat space as special characters too
• at least 10 characters
• at most 128 characters
• not more than 2 identical characters in a row (e.g., 111 not allowed)
• Ensure credential rotation when a password leak, or at the time of compromise identification.
• Include password strength meter to help users create a more complex password and block common and previously breached passwords

Reference:

• https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md

OWASP ASVS

• Verify that user set passwords are at least 12 characters in length
• Verify that passwords 64 characters or longer are permitted.
• Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
• Verify that Unicode characters are permitted in passwords
• Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally
• Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.
• Verify that there are no periodic credential rotation
• Verify that “paste” functionality, browser password helpers
• Verify that anti-automation controls are effective at mitigating breached credential testing
• Verify password hints or knowledge-based authentication (so-called “secret questions”) are not present.

Reference:

• https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

NIST

Summary

• 8 character minimum when a human sets it
• Support at least 64 characters maximum length
• All ASCII characters (including space) should be supported
• Truncation of the secret (password) shall not be performed when processed
• Check chosen password with known password dictionaries
• Allow at least 10 password attempts before lockout
• No complexity requirements
• No password expiration period
• No password hints
• No knowledge-based authentication (e.g. who was your best friend in high school?)
• No SMS for 2FA (use a one-time password from an app like Google Authenticator)

Detailed list

• Passwords must be at least 8 characters in length if chosen by the subscriber.
• Password verifier systems should permit subscriber-chosen passwords at least 64 characters in length.
• All printing ASCII characters as well as the space character should be acceptable in passwords. Acceptance of Unicode characters is also permitted.
• 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, but truncation of the password shall not be performed.
• Verifiers should not impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for passwords.
• Verifiers should not require passwords to be changed arbitrarily (e.g., periodically). However, verifiers shall force a change if there is evidence of compromise of the password.
• Verifiers shall not permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant, and verifiers shall not prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing passwords.
• When processing requests to establish or change passwords, verifiers shall compare the prospective passwords against a list that contains values known to be commonly-used, expected, or compromised. The list may include, but is not limited to:
  • Passwords obtained from previous breach corpuses, e.g. Online Breach Databases^[14], Breached Collections^[15]
  • Dictionary words
  • Passwords consisting of repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’)
  • Context-specific words, such as the name of the service, the username, and derivatives thereof
• If the chosen password is found in the list, the verifier shall advise the subscriber that they need to select a different password and provide the reason for rejection.
• Verifiers should offer guidance to the subscriber, such as a password-strength meter, to assist the user in choosing a strong password. This is particularly important following the rejection of a password on the above list as it discourages trivial modification of blacklisted (and likely very weak) passwords.
• Verifiers shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account.
• Verifiers shall store passwords in a form that is resistant to offline attacks. Passwords shall be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive.

Reference:

• https://pages.nist.gov/800-63-3/sp800-63b.html

PCI-DSS

• Require a minimum length of at least seven characters.
• Contain both numeric and alphabetic characters.
• Users to change passwords at least every 90 days.
• Password parameters are set to require that new passwords cannot be the same as the four previously used passwords.
• First-time passwords for new users, and reset passwords for existing users, are set to a unique value for each user and changed after first use
• User accounts are temporarily locked-out after not more than six invalid access attempts.
• Once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.
• System/session idle time out features have been set to 15 minutes or less.
• Passwords are protected with strong cryptography during transmission and storage.

Reference:

• https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss section 8

ISO 27001

A password management system should:

• enforce the use of individual user IDs and passwords to maintain accountability;
• allow users to select and change their own passwords and include a confirmation procedure to allow for input errors;
• enforce a choice of quality passwords (see 11.3.1);
• enforce password changes (see 11.3.1);
• force users to change temporary passwords at the first log-on (see 11.2.3);
• maintain a record of previous user passwords and prevent re-use;
• not display passwords on the screen when being entered;
• store password files separately from application system data;
• store and transmit passwords in protected (e.g. encrypted or hashed) form. 

Reference:

• ISO 27001 (paid book)
• https://books.google.pl/books?id=TiRIDwAAQBAJ&pg=PA345&dq=%22enforce+the+use+of+Individual+User+IDs+and+Passwords%22&hl=pl&sa=X&ved=0ahUKEwj_7q2QifbjAhVIR5oKHdPUDhcQ6AEIKTAA#v=onepage&q=%22enforce%20the%20use%20of%20Individual%20User%20IDs%20and%20Passwords%22&f=false

Summary

As you can see, the overall trend in password security standards is to give up the restriction of password composition. After many kinds of research, complexity enforcement gives no additional value except the false sense of safety for the users. Longer passwords will give us much more safety, than short but complex. Moreover, they are much easier to remember. 
Below you can see the comparison of time to crack some selected password in two schemas: “short but complex” and “long but simple”.

Password	Time to brute-force (https://howsecureismypassword.net/)
twkeas83	1 minute
Twkeas83	2 hours
Twkeas5+	9 hours
cowabeltadot	4 weeks
cow-belt-dot	18 years

This simple table shows the power of long passwords. Much bigger power than just complex passwords. That should be the primary password security standard.