Overview#

Password Validator (or Verifier) is a Policy Enforcement Point for the Password Policy and more specifically the Password Modification Policy and may be implemented at the Point of Credential Enrollment, Password Change or Password Reset

NIST.SP.800-63B#

NIST.SP.800-63B in section 5.1.1.2. Memorized Secret Verifiers advises in summary the following.
  • SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length.
  • SHOULD permit user-chosen memorized secrets to be up to 64 characters or more in length.
  • All printing ASCII RFC 20 characters as well as the space character SHOULD be acceptable in memorized secrets;
    • Unicode ISO/ISC 10646:2014 characters SHOULD be accepted as well. Verifiers MAY remove multiple consecutive space characters, or all space characters, 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.

If Unicode characters are accepted in memorized secrets, the verifier ] apply the Normalization Process for Stabilized Strings defined in Section 12.1 of Unicode Standard Annex 15 UAX 15 using either the NFKC or NFKD normalization. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully. This process is applied prior to hashing of the byte string representing the memorized secret.

Memorized secrets that are randomly chosen by the Credential Service Provider (e.g., at Credential Enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random bit generator.

Memorized secret verifiers SHALL NOT permit the subscriber to store a "hint" that is accessible to an unauthenticated claimant.

Password Validator also SHALL NOT prompt subscribers to use specific types of information (e.g., "What was the name of your first pet?") when choosing memorized secrets.

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 is not limited to):

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.

Verifiers SHALL implement a throttling mechanism that effectively limits the number of failed authentication attempts an attacker can make on the subscriber’s account as described in Section 5.2.2.

Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.

Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator.

In order to assist the claimant in entering a memorized secret successfully, the verifier SHOULD offer an option to display the secret (rather than a series of dots or asterisks, typically) until it is entered. This allows the claimant to verify their entry if they are 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, particularly on Mobile Devices.

The verifier SHALL use approved encryption and SHALL utilize an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in NIST.SP.800-132. The salt value SHALL be a 32-bit or longer random value generated by an approved random bit generator and stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash Function (e.g., HMAC FIPS 198-1), with the key stored separately from the hashed authenticators (e.g., in a Hardware Security Module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-13) was last changed on 31-Jul-2017 09:37 by jim