Identity Management Security Checklist

AID:

Category:

wdt_ID	AID	Category	Requirement	Guidance	Procedure
1	1	Authentication Assurance Level	Authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators.	A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically-secure device with an integrated biometric sensor that is required to activate the device.	Determine if the Credential Service Provider (CSP) requires the use of two single-factor authenticators or one multi-factor authenticator in all cases at the Authentication Assurance Level (AAL).
2	2	Authentication Assurance Level	If the multi-factor authentication process uses a combination of two single-factor authenticators, then it SHALL include a Memorized Secret authenticator and a possession-based authenticator.	A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically-secure device with an integrated biometric sensor that is required to activate the device.	Determine that all combinations of single-factor authenticators usable at the Authentication Assurance Level (AAL) include both a memorized secret and a possession-based authenticator,
3	3	Authentication Assurance Level	At least one authenticator used at the Authentication Assurance Level (AAL) SHALL be replay resistant.	Replay resistance is a characteristic of most, although not all, physical authenticators. A given output of the authenticator is required to be accepted for only one authentication transaction. For example, the output of a time-based OTP device or an out-of-band device is considered replay resistant if it can only be used for at most one authentication transaction during its validity period. If it can be used for more than one during this period, it is not replay resistant.	Ensure that the authentication transaction cannot be replayed by an attacker. If verifying a physical authenticator that does not implement a cryptographic challenge/response protocol, attempt to authenticate more than once using the same authenticator output (during its validity period, if time-based). If a subsequent authentication succeeds, the test of replay resistance has failed.
4	4	Authentication Assurance Level	Communication between the claimant and verifier SHALL be via an authenticated protected channel.	Communication between claimant and verifier is required to be via an encrypted channel that authenticates the verifier to provide confidentiality of the authenticator output and resistance to MitM attacks. This is typically accomplished using the Transport Level Security (TLS) protocol. Mutual authentication of the communication channel is not required unless that is part of the process of authenticating the claimant. Accordingly, the verifier is only responsible the use of an appropriately secure communications protocol.	Examine the verifier’s API documentation to ensure that TLS or a similarly secure protocol is used in conjunction with an approved encryption protocol
5	5	Authentication Assurance Level	If a device such as a smartphone is used in the authentication process, then the unlocking of that device (typically done using a PIN or biometric) SHALL NOT be considered one of the authentication factors.	This requirement applies to multi-factor authenticators resident on a smartphone or similar device; single-factor authenticators on such devices would only provide a single (physical) authentication factor. Unlocking of a device such as a smartphone may be done for any number of reasons unrelated to authentication, and such devices are normally in an unlocked state for a period of time thereafter. Human action such as entry of a memorized secret or presentation of a biometric factor needs to be provided that is directly associated with the authentication event. Generally, it is not possible for a verifier to know that the device had been locked or if the unlock process met the requirements for the relevant authenticator type.	Attempt to authenticate using supported smartphones and similar devices and observe that presentation of an authentication factor (memorized secret or biometric factor) is required at the time of authentication.
6	6	Authentication Assurance Level	Reauthentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session.	Reauthentication is required to mitigate the risks associated with an authenticated endpoint that has been abandoned by the subscriber or has been misappropriated by an attacker while authenticated. At the Authentication Assurance Level (AAL), providing a memorized secret or biometric factor is sufficient for reauthentication prior to the expiration time.	Authenticate, then idle for 30 minutes and determine that reauthentication is required. Maintain a session for at least 12 hours and observe that reauthentication is required.
7	7	Authentication Assurance Level	Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer.	Reauthentication is required to mitigate the risks associated with an authenticated endpoint that has been abandoned by the subscriber or has been misappropriated by an attacker while authenticated. At the Authentication Assurance Level (AAL), providing a memorized secret or biometric factor is sufficient for reauthentication prior to the expiration time.	Authenticate, then idle for 30 minutes and determine that reauthentication is required. Maintain a session for at least 12 hours and observe that reauthentication is required.
8	8	Authentication Assurance Level	The session SHALL be terminated (i.e., logged out) when either the extended usage or inactivity time limit is reached.	If reauthentication is not performed in accordance with the Authentication Assurance Level (AAL) requirements the session needs to be logged out at that time.	Authenticate, then idle for 30 minutes and determine that the session is logged out. Maintain a session for at least 12 hours and determine that the session is logged out.
9	9	Memorized Secret Verifiers	If chosen by the subscriber, memorized secrets SHALL be at least 8 characters in length.	Memorized secret length is the most reliable metric determining strength against online and offline guessing attacks. The objective is primarily to defend against online attacks (with throttling of guesses) and to provide some protection against offline attacks, with the primary defense for such attacks being secure storage of the verifier.	Determine if the minimum memorized secret length is enforced. Attempt to enroll or change a memorized secret with less than the required length. The user should be re-prompted with an explanation if this occurs.
10	10	Memorized Secret Verifiers	Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.	The availability of memorized secret hints greatly weakens the strength of memorized secret authenticators.	Determine if password hints and prompts are provided to the user.
11	11	Memorized Secret Verifiers	Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.	Prompts for specific information (often called Knowledge-based Authentication or Security Questions) encourage use of the same memorized secrets at multiple sites, which causes a vulnerability to “password stuffing” attacks. This guidance applies to account recovery situations as well as normal authentication.	Attempt to authenticate (including “forgot password” situations) and determine that there is no use of knowledge-based authentication.
12	12	Memorized Secret Verifiers	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.	The maintenance of a list of common memorized secrets that cannot be used by users provides protection against online attacks that might otherwise succeed before throttling mechanisms take effect to defend against these attacks. This is an alternative to the use of composition rules (requirements for particular character types, etc.) and can provide more customized protection against common memorized secrets. This list may include, but is not limited to: • Passwords obtained from previous breach corpuses. • 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.	Determine that a memorized secret “blocklist” exists and is used.
13	13	Memorized Secret Verifiers	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.	Rate limiting restricts the ability of an attacker to make many online guessing attacks on the memorized secret. Other requirements (e.g., minimum length of memorized secrets) depend on the existence of rate limiting, so effective rate limiting is an essential capability. Ideally, a rate limiting mechanism should restrict the attacker as much as possible without creating an opportunity for a denial-of-service attack against the subscriber.	Make repeated attempts to authenticate with the wrong memorized secret and determine that it is not possible to successfully authenticate immediately following a large number of incorrect attempts.
14	14	Memorized Secret Verifiers	Verifiers SHALL force a change of memorized secret if there is evidence of compromise of the authenticator.	Although requiring routine periodic changes to memorized secrets is not recommended, it is important that verifiers have the capability to prompt memorized secrets on an emergency basis if there is evidence of a possible successful attack.	Determine that the capability exists to force memorized secret changes when a compromise is suspected.
15	15	Memorized Secret Verifiers	The verifier SHALL use approved encryption when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.	Cryptography is considered approved if it is specified or adopted in a FIPS or NIST recommendation.	Ensure that only secure, well-vetted cryptographic algorithms are being used.
16	16	OTP Verifiers	OTP authenticators — particularly software-based OTP generators —SHALL NOT facilitate the cloning of the secret key onto multiple devices.	Like other physical authenticators, the use of OTP authenticators is premised upon the authenticator secret being present in a single authenticator so that it proves possession of a specific device. Mechanisms that would facilitate cloning the secret onto multiple devices include the ability to enroll more than one device producing the same OTP output and backup mechanisms, especially when software-based authenticators are used. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Determine that the management of authenticator secrets is sufficiently secure to ensure that authenticators have unique secrets.
17	17	OTP Verifiers	If the nonce used to generate the authenticator output is based on a real-time clock, then the nonce SHALL be changed at least once every 2 minutes.	The authenticator output needs to be changed often enough that there is reasonable assurance that it is in the possession of the claimant and that it is not susceptible to OTP-guessing attacks.	Determine that the output of time-based OTP authenticators changes often enough.
18	18	OTP Verifiers	The OTP value associated with a given nonce SHALL be accepted only once.	fundamental premise of a “one-time” authenticator is that it can be used successfully only once during its validity period.	Determine that it is not possible to successfully authenticate more than once using the same authenticator output (during the validity period, if time-based).
19	19	OTP Verifiers	If a time-based OTP is used, it SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP.	The clocks on time-based authenticators are subject to drift because of cost and environmental factors such as temperature. Accordingly, verifiers need to accept authenticator outputs before and particularly after the intended validity period to allow use by authenticators that are not in synchronization.	Determine that verifiers provide an appropriate “grace period” around the expected validity window.
20	20	OTP Verifiers	Verifiers SHALL accept a given time-based OTP only once during the validity period.	In order to prevent an attacker who gains access to an OTP authenticator output from using it, it is important that the secret only be valid for a single authentication.	Determine that it is not possible to successfully authenticate more than once using the same authenticator output (during the validity period, if time-based).
21	21	Cryptographic Verifiers	If the cryptographic authenticator is software based, the key SHALL be stored in suitably secure storage available to the authenticator application.	Although dependent on the computing device on which the authenticator is operating, authenticator software needs to avail itself of the most secure storage available, considering issues like ability to extract the secret from the device and its potential to be included in backup data. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Ensure that the authenticator is storing secret keys appropriately.
22	22	Cryptographic Verifiers	If the cryptographic authenticator is software based, the key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access.	Although dependent on the computing device on which the authenticator is operating, authenticator software needs to store secret keys in a manner that limits access to keys to the maximum extent possible so that they cannot be accessed by other (possibly rogue) applications and/or users. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Ensure that the authenticator is storing secret keys appropriately.
23	23	Cryptographic Verifiers	If the cryptographic authenticator is software based, it SHALL NOT facilitate the cloning of the secret key onto multiple devices.	Like other physical authenticators, the use of cryptographic authenticators is premised upon the authenticator secret being present in a single authenticator so that it proves possession of a specific device. Mechanisms that would facilitate cloning the secret onto multiple devices include the ability to enroll more than one device with the same key and backup mechanisms, especially when software-based authenticators are used. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Determine that the management of authenticator secrets is sufficiently secure to ensure that authenticators have unique secrets.
24	24	Cryptographic Verifiers	If the authenticator is hardware-based, approved cryptography SHALL be used.	Cryptography is considered approved if it is specified or adopted in a FIPS or NIST recommendation. Since verifiers and cryptographic authenticators must use the same algorithms to successfully authenticate, assessment of the verifier also assesses the authenticators that may be used.	Determine that the secret key is sufficiently complex.
25	25	Cryptographic Verifiers	Cryptographic keys stored by the verifier SHALL be protected against modification.	Protection against modification is required for all keys to ensure that an attacker can’t substitute keys they control, which would permit them to authenticate successfully. This protection could be provided by operating system access controls, or through integrity checks of the stored keys with separately stored hashes.	Determine if keys stored in the verifier have appropriate protection against modification.
	AID	Category