!!! Overview [{$pagename}] (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|Verifier] advises in summary the following: ([{$applicationname}] has rearranged for ease of viewing ) ! [SHALL] or [SHOULD] The verifier [SHALL] use approved [encryption] and [SHALL] utilize an [authenticated] [protected channel|Secure connection] when requesting [memorized secrets] in order to provide resistance to [eavesdropping|Observer] and [MitM|Man-In-The-Middle] [attacks]. __[SHALL]__ require subscriber-chosen memorized secrets to be at least 8 characters in length. [Verifiers] __[SHALL]__ implement a [throttling mechanism|Intruder Detection] that effectively limits the number of failed [authentication] attempts an attacker can make on the subscriber’s account as described in [NIST.SP.800-63B] Section 5.2.2. [Verifiers] __[SHALL]__ store [memorized secrets] in a form that is resistant to [offline|Brute-Force] [attacks]. Secrets [SHALL] be [hashed|Hash] 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|Hash] [authenticators] (e.g., in a [Hardware Security Module]) [SHOULD] be used to further resist [dictionary|Password Dictionary] [attacks] against the stored [hashed|Hash] [authenticators]. [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. __[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|ISO 10646] 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. When processing requests to establish and [change|Password Change] memorized secrets, [verifiers] __[SHALL]__ compare the prospective secrets against a [list|Password Dictionary] that contains values known to be commonly-used, expected, or [compromised|Compromised Credential]. For [example], the list [MAY] include (but is not limited to): * [Passwords] obtained from [Credential Leaked Databases]. * [Dictionary|Password Dictionary] words. * 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 [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. 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]. ! [SHALL NOT] or [SHOULD NOT] 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. Memorized secret [verifiers] __[SHALL NOT]__ permit the subscriber to store a "[hint|Password Hint]" that is accessible to an [unauthenticated] [claimant]. Memorized secret [verifiers] [SHALL NOT] permit the subscriber to store a "[hint|Password Hint]" that is accessible to an [unauthenticated] [claimant]. [{$pagename}] also [SHALL NOT] prompt subscribers to use [specific types of information|Identity questions] (e.g., "What was the name of your first pet?") when choosing memorized secrets. [Verifiers] [SHOULD NOT] impose other [composition|Password Character 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|Password Periodic Changes]) and [SHOULD] only require a change if the subscriber requests a change or there is evidence of compromise of the [authenticator]. ! More on [Unicode] characters 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. !! More Information There might be more information for this subject on one of the following: [{ReferringPagesPlugin before='*' after='\n' }]