Password_secuirty

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