Thu, 29 Aug 2019 02:59:56 +0000

Table of Contents

1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Authenticator Assurance Levels

5. Authenticator and Verifier Requirements

6. Authenticator Lifecycle Requirements

7. Session Management

8. Threats and Security Considerations

9. Privacy Considerations

10. Usability Considerations

11. References

Appendix A. Strength of Memorized Secrets

1. Purpose

This recommendation and its companion documents, SP 800-63-3, SP 800-63A, and SP 800-63C, provide technical guidelines to credential service providers for the implementation of digital authentication.

2. Introduction

Digital authentication is the process of establishing confidence in user identities electronically presented to an information system. E-authentication presents a technical challenge when this process involves the digital authentication of individual people over a network.

The ongoing authentication of subscribers is central to this process. Subscriber authentication is performed by verifying that the claimant controls one or more authenticators (called tokens in earlier editions of SP 800-63) associated with a given subscriber. A successful authentication results in the assertion of an identifier, either pseudonymous or non-pseudonymous, and optionally other identity information, to the relying party (RP).

This document provides guidelines on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AAL). It also provides guidelines on the lifecycle of authenticators, including revocation in the event of loss or theft.

These technical guidelines apply to digital authentication of human users to IT systems over a network. They do not primarily address the authentication of a person who is physically present, for example, for access to buildings, although some credentials that are used remotely may also be used in local authentication. These technical guidelines also establish requirements that Federal IT systems and service providers participating in authentication protocols be authenticated to subscribers. However, these guidelines do not specifically address machine-to-machine (such as router-to-router) authentication, or establish specific requirements for issuing authentication credentials to machines and servers when they are used in e-authentication protocols with people.

The strength of an authentication transaction is characterized by a categorization known as the AAL. Stronger authentication (a higher AAL) requires a higher level of capabilities and/or resources on the part of an attacker in order to successfully authenticate. A high-level summary of the technical requirements for each of the authenticator assurance levels is provided below; see Section 4 and 5 of this document for specific normative requirements.

Authenticator Assurance Level 1 - AAL 1 provides some assurance that the claimant controls the authenticator registered to a subscriber. AAL 1 uses single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove through a secure authentication protocol that he or she possesses and controls the authenticator.

Authenticator Assurance Level 2 – AAL 2 provides high confidence that the claimant controls the authenticator registered to a subscriber. Two different authentication factors are required. Approved cryptographic techniques are required at AAL 2 and above.

Authenticator Assurance Level 3 – AAL 3 provides very high confidence that the claimant controls the authenticator registered to a subscriber. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. AAL 3 is similar to AAL 2 except that a “hard” cryptographic authenticator that also provides impersonation resistance is required.

3. Definitions and Abbreviations

There is a variety of terms used in the area of authentication. While the definitions of many terms are consistent with the original version of SP 800-63, some have changed in this revision. Since there is no single, consistent definition of many of these terms, careful attention to how the terms are defined here is warranted.

The definitions in this section are primarily those that are referenced in this document. Refer to the other documents in the SP 800-63 document family for additional definitions and abbreviations specific to their content.

Active Attack

An attack on the authentication protocol where the attacker transmits data to the claimant, Credential Service Provider, verifier, or Relying Party. Examples of active attacks include man-in-the-middle, impersonation, and session hijacking.

Approved

Federal Information Processing Standard (FIPS) approved or NIST recommended. An algorithm or technique that is either 1) specified in a FIPS or NIST Recommendation, or 2) adopted in a FIPS or NIST Recommendation.

Assertion

A statement from a verifier to a Relying Party (RP) that contains identity information about a subscriber. Assertions may also contain verified attributes.

Assertion Reference

A data object, created in conjunction with an assertion, which identifies the verifier and includes a pointer to the full assertion held by the verifier.

Assurance

In the context of [OMB M-04-04] and this document, assurance is defined as 1) the degree of confidence in the vetting process used to establish the identity of an individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued.

Asymmetric Keys

Two related keys, consisting of a public key and a private key, that are used to perform complementary operations such as encryption and decryption or signature verification and generation.

Attack

An attempt by an unauthorized individual to defeat security controls. For example, to fool a verifier or a Relying Party into believing that the unauthorized individual in question is the subscriber.

Attacker

A party who acts with malicious intent to compromise an information system.

Attribute

A quality or characteristic ascribed to someone or something.

Authenticated Protected Channel

A communication channel that uses approved encryption where the initiator of the connection (client) has authenticated the recipient (server). Authenticated protected channels provide confidentiality and man-in-the-middle protection and are frequently used in the user authentication process. TLS [BCP 195] is an example of an authenticated protected channel when the certificate presented by the recipient is verified by the initiator.

Authentication

The process of establishing confidence in the identity of users or information systems. Authentication of users (subscribers) implies confirmation of the subscriber’s presence and intent to authenticate.

Authentication Factor

The three types of authentication factors are something you know, something you have, and something you are. Every authenticator has one or more authentication factors.

Authentication Protocol

A defined sequence of messages between a claimant and a verifier that demonstrates that the claimant has possession and control of one or more valid authenticators to establish his/her identity. Secure authentication protocols also demonstrate to the claimant that he or she is communicating with the intended verifier.

Authentication Protocol Run

An exchange of messages between a claimant and a verifier that results in authentication (or authentication failure) between the two parties.

Authentication Secret

A generic term for any secret value that could be used by an attacker to impersonate the subscriber in an authentication protocol.

These are further divided into short-term authentication secrets, which are only useful to an attacker for a limited period of time, and long-term authentication secrets, which allow an attacker to impersonate the subscriber until they are manually reset. The authenticator secret is the canonical example of a long term authentication secret, while the authenticator output, if it is different from the authenticator secret, is usually a short term authentication secret.

Authenticator

Something that the claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the claimant’s identity. In previous editions of SP 800-63, this was referred to as a token.

Authenticator Assurance Level (AAL)

A metric describing robustness of the authentication process proving that the claimant is in control of a given subscriber’s authenticator(s).

Authenticator Output

The output value generated by an authenticator. The ability to generate valid authenticator outputs on demand proves that the claimant possesses and controls the authenticator. Protocol messages sent to the verifier are dependent upon the authenticator output, but they may or may not explicitly contain it.

Authenticator Secret

The secret value contained within an authenticator.

Bearer Assertion

An assertion that does not provide a mechanism for the subscriber to prove that he or she is the rightful owner of the assertion. The RP has to assume that the assertion was issued to the subscriber who presents the assertion or the corresponding assertion reference to the RP.

Biometrics

Automated recognition of individuals based on their behavioral and biological characteristics.

In this document, biometrics may be used to unlock multi-factor authenticators and prevent repudiation of registration.

Challenge-Response Protocol

An authentication protocol where the verifier sends the claimant a challenge (usually a random value or a nonce) that the claimant combines with a secret (such as by hashing the challenge and a shared secret together, or by applying a private key operation to the challenge) to generate a response that is sent to the verifier. The verifier can independently verify the response generated by the claimant (such as by re-computing the hash of the challenge and the shared secret and comparing to the response, or performing a public key operation on the response) and establish that the claimant possesses and controls the secret.

Claimant

A party whose identity is to be verified using one or more authentication protocols.

Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)

An interactive feature added to web-forms to distinguish use of the form by humans as opposed to automated agents. Typically, it requires entering text corresponding to a distorted image or from a sound stream.

Credential

An object or data structure that authoritatively binds an identity (and optionally, additional attributes) to an authenticator possessed and controlled by a subscriber.

While common usage often assumes that the credential is maintained by the subscriber, this document also uses the term to refer to electronic records maintained by the CSP which establish a binding between the subscriber’s authenticator(s) and their identity.

Credential Service Provider (CSP)

A trusted entity that issues or registers subscriber authenticators and issues electronic credentials to subscribers. The CSP may encompass verifiers that it operates. A CSP may be an independent third party, or may issue credentials for its own use.

Cross Site Request Forgery (CSRF)

An attack in which a subscriber who is currently authenticated to an RP and connected through a secure session, browses to an attacker’s website which causes the subscriber to unknowingly invoke unwanted actions at the RP.

For example, if a bank website is vulnerable to a CSRF attack, it may be possible for a subscriber to unintentionally authorize a large money transfer, merely by viewing a malicious link in a webmail message while a connection to the bank is open in another browser window.

Cross Site Scripting (XSS)

A vulnerability that allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts generated by the target website and can therefore compromise the confidentiality and integrity of data transfers between the website and client. Websites are vulnerable if they display user supplied data from requests or forms without sanitizing the data so that it is not executable.

Cryptographic Key

A value used to control cryptographic operations, such as decryption, encryption, signature generation or signature verification. For the purposes of this document, key requirements shall meet the minimum requirements stated in Table 2 of NIST SP 800-57 Part 1.

See also Asymmetric keys, Symmetric key.

Cryptographic Authenticator

An authenticator where the secret is a cryptographic key. A hardware cryptographic authenticator is a cryptographic module containing one or more cryptographic keys.

Cryptographic Module

A set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation).

Data Integrity

The property that data has not been altered by an unauthorized entity.

Derived Credential

A credential issued based on proof of possession and control of one or more authenticators associated with a previously issued credential, so as not to duplicate the identity proofing process.

Digital Authentication

The process of establishing confidence in user identities electronically presented to an information system. In previous editions of SP 800-63, this was referred to as Electronic Authentication.

Digital Signature

An asymmetric key operation where the private key is used to digitally sign data and the public key is used to verify the signature. Digital signatures provide authenticity protection, integrity protection, and non-repudiation but not confidentiality protection.

Eavesdropping Attack

An attack in which an attacker listens passively to the authentication protocol to capture information which can be used in a subsequent active attack to masquerade as the claimant.

Electronic Authentication (E-Authentication)

See Digital Authentication.

Entropy

A measure of the amount of uncertainty that an attacker faces to determine the value of a secret. Entropy is usually stated in bits. A value having n bits of entropy has the same degree of uncertainty as a uniformly-distributed n-bit random value.

Equal Error Rate (EER)

The value where the false match rate (FMR) and false non-match rate (FNMR) of a sensor are equal. EER is a figure of merit for the sensor; the lower the EER is, the more certain the sensor’s decision is likely to be.

Federal Information Security Management Act (FISMA)

Title III of the E-Government Act requiring each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

Federal Information Processing Standard (FIPS)

Under the Information Technology Management Reform Act (Public Law 104-106), the Secretary of Commerce approves standards and guidelines that are developed by the National Institute of Standards and Technology (NIST) for Federal computer systems. These standards and guidelines are issued by NIST as Federal Information Processing Standards (FIPS) for use government-wide. NIST develops FIPS when there are compelling Federal government requirements such as for security and interoperability and there are no acceptable industry standards or solutions. See background information for more details.

FIPS documents are available online through the FIPS home page: http://www.nist.gov/itl/fips.cfm

Hash Function

A function that maps a bit string of arbitrary length to a fixed length bit string. Approved hash functions satisfy the following properties:

1. (One-way) It is computationally infeasible to find any input that maps to any pre-specified output, and

2. (Collision resistant) It is computationally infeasible to find any two distinct inputs that map to the same output.

Holder-of-Key Assertion

An assertion that contains a reference to a symmetric key or a public key (corresponding to a private key) held by the subscriber. The RP may authenticate the subscriber by verifying that he or she can indeed prove possession and control of the referenced key.

Identity

A set of attributes that uniquely describe a person within a given context.

Identity Assurance Level (IAL)

A metric describing degree of confidence that the Applicant’s Claimed Identity is their real identity.

Kerberos

A widely used authentication protocol developed at MIT. In “classic” Kerberos, users share a secret password with a Key Distribution Center (KDC). The user, Alice, who wishes to communicate with another user, Bob, authenticates to the KDC and is furnished a “ticket” by the KDC to use to authenticate with Bob.

When Kerberos authentication is based on passwords, the protocol is known to be vulnerable to offline dictionary attacks by eavesdroppers who capture the initial user-to-KDC exchange. Longer password length and complexity provide some mitigation to this vulnerability, although sufficiently long passwords tend to be cumbersome for users.

Man-in-the-Middle Attack (MitM)

An attack on the authentication protocol in which the attacker positions himself or herself in between the claimant and verifier so that he or she can intercept and/or alter data traveling between them.

Message Authentication Code (MAC)

A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. MACs provide authenticity and integrity protection, but not non-repudiation protection.

Mobile Code

Executable code that is normally transferred from its source to another computer system for execution. This transfer is often through the network (e.g., JavaScript embedded in a web page) but may transfer through physical media as well.

Multi-Factor

A characteristic of an authentication system or an authenticator that requires more than one authentication factor for successful authentication. Multi-factor authentication can be performed using a single authenticator that provides more than one factor or by a combination of authenticators that provide different factors.

The three authentication factors are something you know, something you have, and something you are.

Network

An open communications medium, typically the Internet, that is used to transport messages between the claimant and other parties. Unless otherwise stated, no assumptions are made about the security of the network; it is assumed to be open and subject to active (i.e., impersonation, man-in-the-middle, session hijacking) and passive (i.e., eavesdropping) attack at any point between the parties (e.g., claimant, verifier, CSP or RP).

Nonce

A value used in security protocols that is never repeated with the same key. For example, nonces used as challenges in challenge-response authentication protocols SHALL not be repeated until authentication keys are changed. Otherwise, there is a possibility of a replay attack. Using a nonce as a challenge is a different requirement than a random challenge, because a nonce is not necessarily unpredictable.

Offline Attack

An attack where the attacker obtains some data (typically by eavesdropping on an authentication protocol run or by penetrating a system and stealing security files) that he/she is able to analyze in a system of his/her own choosing.

Online Attack

An attack against an authentication protocol where the attacker either assumes the role of a claimant with a genuine verifier or actively alters the authentication channel.

Online Guessing Attack

An attack in which an attacker performs repeated logon trials by guessing possible values of the authenticator output.

Passive Attack

An attack against an authentication protocol where the attacker intercepts data traveling along the network between the claimant and verifier, but does not alter the data (i.e., eavesdropping).

Password

A secret that a claimant memorizes and uses to authenticate his or her identity. Passwords are typically character strings.

Personal Identification Number (PIN)

A password consisting only of decimal digits.

Pharming

An attack in which an attacker corrupts an infrastructure service such as DNS (Domain Name Service) causing the subscriber to be misdirected to a forged verifier/RP, which could cause the subscriber to reveal sensitive information, download harmful software or contribute to a fraudulent act.

Phishing

An attack in which the subscriber is lured (usually through an email) to interact with a counterfeit verifier/RP and tricked into revealing information that can be used to masquerade as that subscriber to the real verifier/RP.

Possession and control of an authenticator

The ability to activate and use the authenticator in an authentication protocol.

Practice Statement

A formal statement of the practices followed by the parties to an authentication process (i.e., RA, CSP, or verifier). It usually describes the policies and practices of the parties and can become legally binding.

Private Credentials

Credentials that cannot be disclosed by the CSP because the contents can be used to compromise the authenticator.

Private Key

The secret part of an asymmetric key pair that is used to digitally sign or decrypt data.

Protected Session

A session wherein messages between two participants are encrypted and integrity is protected using a set of shared secrets called session keys.

A participant is said to be authenticated if, during the session, he, she or it proves possession of an authenticator in addition to the session keys, and if the other party can verify the identity associated with that authenticator. If both participants are authenticated, the protected session is said to be mutually authenticated.

Public Credentials

Credentials that describe the binding in a way that does not compromise the authenticator.

Public Key

The public part of an asymmetric key pair that is used to verify signatures or encrypt data.

Public Key Certificate

A digital document issued and digitally signed by the private key of a certificate authority that binds the name of a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has sole control and access to the private key. See also [RFC 5280].

Public Key Infrastructure (PKI)

A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Reauthentication

The process of confirming the subscriber’s continued presence and intent to be authenticated during an extended usage session.

Registration

The process through which an applicant applies to become a subscriber of a CSP and the CSP validates the identity of the applicant.

Relying Party (RP)

An entity that relies upon the subscriber’s authenticator and credentials or a verifier’s assertion of a claimant’s identity, typically to process a transaction or grant access to information or a system.

Remote

(As in remote authentication or remote transaction) An information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls.

Note: Any information exchange across the Internet is considered remote.

Replay Attack

An attack in which the attacker is able to replay previously captured messages (between a legitimate claimant and a verifier) to masquerade as that claimant to the verifier or vice versa.

Risk Assessment

The process of identifying the risks to system security and determining the probability of occurrence, the resulting impact, and additional safeguards that would mitigate this impact. Part of Risk Management and synonymous with Risk Analysis.

Salt

A non-secret value that is used in a cryptographic process, usually to ensure that the results of computations for one instance cannot be reused by an attacker.

Secondary Authenticator

A temporary secret, issued by the verifier to a successfully authenticated subscriber as part of an assertion protocol. This secret is subsequently used, by the subscriber, to authenticate to the RP.

Examples of secondary authenticators include bearer assertions, assertion references, and Kerberos session keys.

Secure Sockets Layer (SSL)

See Transport Layer Security (TLS).

Security Assertion Mark-up Language (SAML)

An XML-based security specification developed by the Organization for the Advancement of Structured Information Standards (OASIS) for exchanging authentication (and authorization) information between trusted entities over the Internet. See [SAML].

SAML Authentication Assertion

A SAML assertion that conveys information from a verifier to an RP about a successful act of authentication that took place between the verifier and a subscriber.

Session

A persistent interaction between a subscriber and an endpoint, either an RP or a CSP. A session begins with an authentication event and ends with a session termination event. A session is bound by use of a session secret that the subscriber’s software (a browser, application, or OS) can present to the RP or CSP in lieu of the subscriber’s authentication credentials.

Session Hijack Attack

An attack in which the attacker is able to insert himself or herself between a claimant and a verifier subsequent to a successful authentication exchange between the latter two parties. The attacker is able to pose as a subscriber to the verifier or vice versa to control session data exchange. Sessions between the claimant and the Relying Party can also be similarly compromised.

Shared Secret

A secret used in authentication that is known to the claimant and the verifier.

Side Channel Attack

An attack enabled by leakage of information from a physical cryptosystem. Timing, power consumption, electromagnetic and acoustic emissions are examples of characteristics that could be exploited in a side-channel attack.

Social Engineering

The act of deceiving an individual into revealing sensitive information by associating with the individual to gain confidence and trust.

Special Publication (SP)

A type of publication issued by NIST. Specifically, the Special Publication 800-series reports on the Information Technology Laboratory’s research, guidelines, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.

Subscriber

A party who has received a credential bound to an authenticator from a CSP.

Symmetric Key

A cryptographic key that is used to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt, or create a message authentication code and to verify the code.

Token

See Authenticator.

Token Authenticator

See Authenticator Output.

Token Secret

See Authenticator Secret.

Transport Layer Security (TLS)

An authentication and security protocol widely implemented in browsers and web servers. TLS is defined by [RFC 5246]. TLS is similar to the older Secure Sockets Layer (SSL) protocol, and TLS 1.0 is effectively SSL version 3.1. NIST [SP 800-52], Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations specifies how TLS is to be used in government applications.

Trust Anchor

A public or symmetric key that is trusted because it is directly built into hardware or software, or securely provisioned via out-of-band means, rather than because it is vouched for by another trusted entity (e.g. in a public key certificate).

Usability

Per ISO/IEC 9241-11: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use

Verifier

An entity that verifies the claimant’s identity by verifying the claimant’s possession and control of one or two authenticators using an authentication protocol. To do this, the verifier may also need to validate credentials that link the authenticator(s) and identity and check their status.

Verifier Impersonation

A scenario where the attacker impersonates the verifier in an authentication protocol, usually to capture information that can be used to masquerade as a subscriber to the real verifier. In previous editions of SP 800-63, authentication protocols that are resistant to verifier impersonation have been described as “strongly man-in-the-middle resistant”.

Weakly Bound Credentials

Credentials that are bound to a subscriber in a manner than can be modified without invalidating the credential.

Zeroize

Overwrite a memory location with data consisting entirely of bits with the value zero so that the data is destroyed and not recoverable. This is often contrasted with deletion methods that merely destroy reference to data within a file system rather than the data itself.

Zero-knowledge Password Protocol

A password based authentication protocol that allows a claimant to authenticate to a verifier without revealing the password to the verifier. Examples of such protocols are EKE, SPEKE and SRP.

4. Authenticator Assurance Levels

In order to satisfy the requirements of a given Authenticator Assurance Level (AAL), a claimant SHALL be authenticated with at least a given level of strength to be recognized as a subscriber. The result of an authentication process is an identifier, that MAY be pseudonymous, that SHALL be used each time that subscriber authenticates to that relying party. Optionally, other attributes that identify the subscriber as a unique person may also be provided.

Detailed normative requirements for authenticators and verifiers at each AAL are provided in Section 5.

FIPS 140 requirements are satisfied by [FIPS 140-2] or newer revisions.

Table 4-1 lists strict adherence to M-04-04 Level of Assurance, mapping the corresponding Authenticator Assurance Levels.

M-04-04 Level of Assurance (LOA)	Authenticator Assurance Level (AAL)
1	1
2	2 or 3
3	2 or 3
4	3

However, Table 4-2 shows the expanded set of AALs that are allowable to meet M-04-04 Levels of Assurance. Agencies SHALL select the corresponding AAL based on the assessed M-04-04 LOA.

M-04-04 Level of Assurance	Authenticator Assurance Level
1	1, 2 or 3
2	2 or 3
3	2 or 3
4	3

4.1. Authenticator Assurance Level 1

AAL 1 provides some assurance that the claimant controls the authenticator registered to a subscriber. AAL 1 uses single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove through a secure authentication protocol that he or she possesses and controls the authenticator.

4.1.1. Permitted Authenticator Types

Authenticator Assurance Level 1 permits the use of any of the following authenticator types, defined in Section 5:

• Memorized Secret
• Look-up Secret
• Out of Band (Partially deprecated; see Section 5.1.3 for more details)
• Single Factor OTP Device
• Multi-Factor OTP Device
• Single Factor Cryptographic Software
• Single Factor Cryptographic Device
• Multi-Factor Cryptographic Software
• Multi-Factor Cryptographic Device

4.1.2. Authenticator and Verifier Requirements

Cryptographic authenticators used at AAL 1 SHALL use approved cryptography. Software-based authenticators that operate within the context of a general purpose operating system MAY, where practical, attempt to detect compromise of the platform in which they are running (e.g., by malware or “jailbreak”) and SHOULD decline to operate when such a compromise is detected.

Communication between the claimant and channel (the primary channel in the case of an Out of Band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle attacks.

Verifiers operated by government agencies at AAL 1 SHALL be validated to meet the requirements of [FIPS 140] Level 1.

4.1.3. Assertion Requirements

In order to be valid at AAL 1, authentication assertions SHALL meet the requirements defined in SP 800-63C. Bearer assertions MAY be used.

4.1.4. Reauthentication

At AAL 1, reauthentication of the subscriber SHOULD be repeated at least once per 30 days, regardless of user activity.

4.1.5. Security Controls

The CSP SHOULD employ appropriately tailored security controls from the low baseline of security controls defined in [SP 800-53] or equivalent industry standard and SHOULD ensure that the minimum assurance requirements associated with the low baseline are satisfied.

4.1.6. Records Retention

The CSP shall comply with their respective records retention policies in accordance with applicable laws and regulations. If the CSP opts to retain records in the absence of any legal requirements, the CSP SHALL conduct a privacy risk assessment to determine how long any records should be retained.

4.2. Authenticator Assurance Level 2

AAL 2 provides high confidence that the claimant controls the authenticator registered to a subscriber. Two different authentication factors are required. Approved cryptographic techniques are required at AAL 2 and above.

4.2.1. Permitted Authenticator Types

At AAL 2, it is required to have (a) a multi-factor authenticator, or (b) a combination of two single-factor authenticators. Authenticator requirements are specified in Section 5.

When a multi-factor authenticator is used, any of the following may be used:

• Multi-Factor OTP Device
• Multi-Factor Cryptographic Software
• Multi-Factor Cryptographic Device

When a combination of two single-factor authenticators is used, it SHALL include a Memorized Secret authenticator and one possession-based (“something you have”) authenticator from the following list:

• Look-up Secret
• Out of Band
• Single Factor OTP Device
• Single Factor Cryptographic Software
• Single Factor Cryptographic Device

Note: The requirement for a memorized secret authenticator above derives from the need for two different types of authentication factors to be used. All biometric authenticators compliant with this specification are multi-factor, so something you know (a memorized secret) is the remaining possibility.

4.2.2. Authenticator and Verifier Requirements

Cryptographic authenticators used at AAL 2 SHALL use approved cryptography. Authenticators procured by government agencies SHALL be validated to meet the requirements of [FIPS 140] Level 1. Software-based authenticators that operate within the context of a general purpose operating system MAY, where practical, attempt to detect compromise of the platform in which they are running (e.g., by malware or “jailbreak”) and SHOULD decline to operate when such a compromise is detected.

Communication between the claimant and channel (the primary channel in the case of an Out of Band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle attacks.

Verifiers operated by government agencies at AAL 2 SHALL be validated to meet the requirements of [FIPS 140] Level 1.

4.2.3. Assertion Requirements

In order to be valid at AAL 2, authentication assertions SHALL meet the requirements defined in SP 800-63C. Bearer assertions MAY be used.

4.2.4. Reauthentication

At AAL 2, authentication of the subscriber SHALL be repeated at least once per 12 hours, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following no more than 30 minutes of user inactivity. The CSP MAY prompt the user to cause activity just before the inactivity timeout, if desired. Reauthentication MAY use a single authentication factor.

4.2.5. Security Controls

The CSP SHOULD employ appropriately tailored security controls from the moderate baseline of security controls defined in [SP 800-53] or equivalent industry standard and SHOULD ensure that the minimum assurance requirements associated with the moderate baseline are satisfied.

4.2.6. Records Retention

CSPs shall comply with their respective records retention policies in accordance with whatever laws and/or regulations apply to those entities. If the CSP opts to retain records in the absence of any legal requirements, the CSP SHALL conduct a privacy risk assessment to determine how long any records should be retained.

4.3. Authenticator Assurance Level 3

AAL 3 provides very high confidence that the claimant controls the authenticator registered to a subscriber. Authentication at AAL 3 is based on proof of possession of a key through a cryptographic protocol. AAL 3 is similar to AAL 2 except that a “hard” cryptographic authenticator that also provides verifier impersonation resistance is required.

4.3.1. Permitted Authenticator Types

Authentication Assurance Level 3 requires the use of one of three kinds of hardware devices:

• Multi-Factor Cryptographic Device
• Single-Factor Cryptographic Device used in conjunction with Memorized Secret

All cryptographic device authenticators used at AAL 3 SHALL be verifier impersonation resistant as described in section 5.2.5.

4.3.2. Authenticator and Verifier Requirements

Communication between the claimant and channel SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle attacks. At least one authenticator used in each AAL 3 authentication SHALL be verifier impersonation resistant as described in Section 5.2.5.

Multi-factor authenticators used at AAL 3 SHALL be hardware cryptographic modules validated at [FIPS 140] Level 2 or higher overall with at least [FIPS 140] Level 3 physical security. Single-factor cryptographic devices used at AAL 3 SHALL be validated at [FIPS 140] Level 1 or higher overall with at least [FIPS 140] Level 3 physical security.

Verifiers at AAL 3 SHALL be validated at [FIPS 140] Level 1 or higher.

4.3.3. Assertion Requirements

In order to be valid at AAL 3, authentication assertions SHALL meet the requirements of proof-of-possession assertions as defined in SP 800-63C.

4.3.4. Reauthentication

At AAL 3, authentication of the subscriber SHALL be repeated at least once per 12 hours, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following a period of no more than 15 minutes of user inactivity. Reauthentication SHALL use both authentication factors. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

4.3.5. Security Controls

The CSP SHOULD employ appropriately tailored security controls from the high baseline of security controls defined in [SP 800-53] or an equivalent industry standard and SHOULD ensure that the minimum assurance requirements associated with the high baseline are satisfied.

4.3.6. Records Retention

The CSP SHALL comply with their respective records retention policies in accordance with whatever laws and/or regulations apply to those entities. If the CSP opts to retain records in the absence of any legal requirements, the CSP SHALL conduct a privacy risk assessment to determine how long any records should be retained.

4.4. Privacy Requirements

The CSP SHOULD employ appropriately tailored privacy controls defined in [SP 800-53] or equivalent industry standard.

CSPs SHALL NOT use or disclose information about authenticators for any purpose other than conducting authentication or to comply with law or legal process, unless the CSP provides clear notice and obtains consent from the subscriber for additional uses. CSPs MAY NOT make consent a condition of the service. Care SHALL be taken to ensure that use of such information is limited to its original purpose for collection. If the use of such information does not fall within uses related to authentication or to comply with law or legal process, the CSP SHALL provide notice and obtain consent from the subscriber. This notice SHOULD follow the same principles as described in Notice and Consent in SP 800-63A Section 8.2 and SHOULD not be rolled up into a legalistic privacy policy or general terms and conditions. Rather, if there are uses outside the bounds of these explicit purposes, the subscriber SHOULD be provided with a meaningful way to understand the purpose for additional uses, and the opportunity to accept or decline.

Regardless of whether the CSP is an agency or private sector provider, the following requirements apply to the agency offering or using the authentication service:

1. The agency SHALL consult with their Senior Agency Official for Privacy to conduct an analysis to determine whether the collection of Personally Identifiable Information (PII) to issue or maintain authenticators triggers the requirements of the Privacy Act of 1974 [PrivacyAct].
   • The agency SHALL publish a System of Records Notice to cover such collections, as applicable.
   • The agency SHALL consult with their Senior Agency Official for Privacy to conduct an analysis to determine whether the collection of PII to issue or maintain authenticators triggers the requirements of the E-Government Act of 2002 [E-Gov].
   • The agency SHALL publish a Privacy Impact Assessment to cover such collection, as applicable.

4.5. Summary of Requirements

(Non-normative; refer to preceding sections for normative requirements)

Table 4-3 summarizes the requirements for each of the authenticator assurance levels:

Requirement	AAL 1	AAL 2	AAL 3
Permitted authenticator types	Memorized Secret; Look-up Secret; Out of Band; SF OTP Device; MF OTP Device; SF Crypto Software; SF Crypto Device; MF Crypto Software; MF Crypto Device	MF OTP Device; MF Crypto Software; MF Crypto Device; or memorized secret plus:  • Look-up Secret  • Out of Band  • SF OTP Device  • SF Crypto Software  • SF Crypto Device	MF Crypto Device SF Crypto Device plus   Memorized Secret
FIPS 140 verification	Level 1 (Government agency verifiers)	Level 1 (Government agency authenticators and verifiers)	Level 2 overall (MF authenticators) Level 1 overall (verifiers and SF Crypto Devices) Level 3 physical security (all authenticators)
Assertions	Bearer or proof of possession	Bearer or proof of possession	Proof of possession only
Reauthentication	30 days	12 hours or 30 minutes inactivity; may use one authentication factor	12 hours or 15 minutes inactivity; shall use both authentication factors
Security controls	[SP 800-53] Low Baseline (or equivalent)	[SP 800-53] Moderate Baseline (or equivalent)	[SP 800-53] High Baseline (or equivalent)
MITM resistance	Required	Required	Required
Verifier impersonation resistance	Not required	Not required	Required

5. Authenticator and Verifier Requirements

This section provides the detailed requirements specific for each of the authenticator types. With the exception of reauthentication requirements specified in Section 4, the technical requirements for each of the authenticator types is the same regardless of the AAL at which it is used.

5.1. Requirements by Authenticator Type

5.1.1. Memorized Secrets

5.1.1.1. Memorized Secret Authenticators

Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber; memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. Since the CSP or verifier may disallow some choices of memorized secrets based on their appearance on a blacklist of compromised values, the subscriber SHALL choose a different memorized secret if a choice is rejected. No other complexity requirements for memorized secrets SHOULD be imposed; a rationale for this is presented in Appendix A.

5.1.1.2. Memorized Secret Verifiers

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit user-chosen memorized secrets to be at least 64 characters 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 SHOULD 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 CSP (e.g., at 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. Verifiers 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 of known commonly-used, expected, and/or compromised values. For example, the list MAY include (but is not limited to):

• Passwords obtained from previous breach corpuses
• Dictionary words
• Context specific words, such as the name of the service, the username, and derivates thereof

If the chosen secret is found in the list, the subscriber SHALL be advised that they need to select a different secret because their previous choice was commonly used, and be required 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 (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

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) as it is typed. The verifier SHALL hide the character after it is displayed for a time sufficient for the claimant to see the character. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed.

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 man-in-the-middle 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 [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random bit generator and is 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), 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.

5.1.2. Look-up Secrets

5.1.2.1 Look-up Secret Authenticators

CSPs creating look-up secret authenticators SHALL use an approved random bit generator to generate the list of secrets, and SHALL deliver the authenticator securely to the subscriber. Look-up secrets SHALL have at least 64 bits of entropy, or SHALL have at least 20 bits of entropy if the number of failed authentication attempts is limited as described in Section 5.2.2.

If the authenticator uses look-up secrets sequentially from a list, the subscriber MAY dispose of used secrets, but only after a successful authentication.

5.1.2.2. Look-up Secret Verifiers

Verifiers of look-up secrets SHALL prompt the claimant for the next secret from their authenticator or for a specific (i.e., numbered) secret. A given secret from an authenticator SHALL be used successfully only once; therefore, a given authenticator can only be used for a finite number of successful authentications. If the look-up secret is derived from a grid card, each cell of the grid SHALL be used only once.

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a “salt” value using an approved hash function as described in [SP 800-132]. The “salt” value SHALL be a 128 bit (or longer) random value generated by an approved random bit generator that is stored along with the hash result. A keyed hash function (e.g., HMAC [FIPS198-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.

Look-up secrets SHALL be generated using an approved random bit generator and SHALL have at least 20 bits of entropy. When look-up secrets have less than 64 bits of entropy, the verifier 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.

The verifier SHALL use approved encryption and SHALL utilize an authenticated protected channel when requesting look-up secrets in order to provide resistance to eavesdropping and man-in-the-middle attacks.

5.1.3. Out-of-Band Devices

5.1.3.1. Out-of-Band Authenticators

The out-of-band authenticator SHALL establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel, even if it terminates on the same device, provided the device does not leak information from one to the other without the authorization of the claimant.

The out-of-band device SHALL be uniquely addressable and communication over the secondary channel SHALL be private. Some voice-over-IP telephone services can deliver text messages and voice calls without the need for possession of a physical device; these SHALL NOT be used for out-of-band authentication. Ability to receive email messages or other types of instant message does not generally prove the possession of a specific device, and therefore SHALL NOT be used as out-of-band authentication methods. Mechanisms such as smartphone applications that employ secure communications protocols and uniquely identify the out-of-band device SHOULD be used for out-of-band authentication.

The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways in communicating with the verifier:

• Establish an authenticated protected channel to the verifier using approved cryptography. The key used SHALL be stored in the most secure storage available on the device (e.g., keychain storage, trusted platform module, or trusted execution environment if available).

• Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device. This method SHALL only be used if a secret is being sent from the verifier to the out-of-band device via the telephone network (SMS or voice).

If a secret is sent by the verifier to the out-of-band device, the device SHOULD NOT display the authentication secret on a device while it is locked by the owner (i.e., requires an entry of a PIN or passcode). However, authenticators MAY indicate the receipt of an authentication secret on a locked device.

If the out-of-band authenticator sends an approval message over the secondary communication channel (rather than by the claimant transferring a received secret to the primary communication channel), it SHALL do one of the following:

• The authenticator SHALL accept transfer of the secret from the primary channel which it SHALL send to the verifier over the secondary channel to associate the approval with the authentication transaction. The claimant MAY perform the transfer manually or use a technology such as a barcode or QR code to effect the transfer.

• The authenticator SHALL present a secret received via the secondary channel from the verifier and prompt the claimant to verify the consistency of that secret with the primary channel, prior to accepting a yes/no response from the claimant. It SHALL then send that response to the verifier.

5.1.3.2. Out-of-Band Verifiers

Due to the risk that SMS messages or voice calls may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out-of-band verification is to be made using the public switched telephone network (PSTN), the verifier SHALL verify that the pre-registered telephone number being used is not associated with a VoIP (or other software-based) service. It then sends the SMS or voice message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change.

Note: Out-of-band authentication using the PSTN (SMS or voice) is deprecated, and is being considered for removal in future editions of this guideline.

If out-of-band verification is to be made using a secure application (e.g., on a smart phone), the verifier MAY send a push notification to that device. The verifier then waits for a establishment of an authenticated protected channel and verifies the authenticator’s identifying key. The verifier SHALL NOT store the identifying key itself, but SHALL use a verification method such as hashing (using an approved hash function) or proof of possession of the identifying key to uniquely identify the authenticator. Once authenticated, the verifier transmits the authentication secret to the authenticator.

Depending on the type of out-of-band authenticator, one of the following SHALL take place:

• Transfer of secret to primary channel: The verifier MAY signal the device containing the subscriber’s authenticator to indicate readiness to authenticate. It SHALL then transmit a random secret to the out-of-band authenticator. The verifier SHALL then wait for the secret to be returned on the primary communication channel.

• Transfer of secret to secondary channel: The verifier SHALL display a random authentication secret to the claimant via the primary channel. It SHALL then wait for the secret to be returned on the secondary channel from the claimant’s out-of-band authenticator.

• Verification of secrets by claimant: The verifier SHALL display a random authentication secret to the claimant via the primary channel, and SHALL send the same secret to the out-of-band authenticator via the secondary channel for presentation to the claimant. It SHALL then wait for an approval (or disapproval) message via the secondary channel.

In all cases, the authentication SHALL be considered invalid if not completed within 5 minutes.

The verifier SHALL generate random authentication secrets with at least 20 bits of entropy using an approved random bit generator. If the authentication secret has less than 64 bits of entropy, the verifier 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.

5.1.4. Single Factor OTP Device

5.1.4.1. Single Factor OTP Authenticators

Single factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the lifetime of the device. The second is a nonce that is changed each time the authenticator is used or is based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP 800-131A] (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime.

The authenticator output is obtained by using an approved block cipher or hash function to combine the key and nonce in a secure manner. The authenticator output MAY be truncated to as few as 6 decimal digits (approximately 20 bits of entropy).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes. The OTP value associated with a given nonce SHALL be accepted only once.

5.1.4.2. Single Factor OTP Verifiers

Single factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator. As such, the symmetric keys used by authenticators are also present in the verifier, and SHALL be strongly protected against compromise.

When a multi-factor OTP authenticator is being associated with a subscriber account, the verifier (or associated CSP) SHALL obtain secrets required to duplicate the authenticator output from the authenticator source (typically its manufacturer) using approved cryptography.

The verifier SHALL use approved encryption and SHALL utilize an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and man-in-the-middle attacks. Time-based one-time passwords SHALL have a lifetime of less than 2 minutes.

If the authenticator output has less than 64 bits of entropy, the verifier 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.

5.1.5. Multi-Factor OTP Devices

5.1.5.1. Multi-Factor OTP Authenticators

Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators (see Section 5.1.4.1), except that they require the entry of either a memorized secret or use of a biometric to obtain a password from the authenticator. Each use of the authenticator SHALL require the input of the additional factor.

The authenticator output SHALL have at least 6 decimal digits (approximately 20 bits) of entropy. The output SHALL be generated by using an approved block cipher or hash function to combine a symmetric key stored on a personal hardware device with a nonce to generate a one-time password. The nonce MAY be based on the date and time or on a counter generated on the device.

Any memorized secret used by the authenticator for activation SHALL be at least 6 decimal digits (approximately 20 bits) in length or of equivalent complexity and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on number of successive authentication failures.

The unencrypted key and activation secret or biometric sample (and any biometric data derived from the biometric sample such as a probe produced through signal processing) SHALL be erased from memory immediately after a password has been generated.

5.1.5.2. Multi-Factor OTP Verifiers

Multi-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator, but without the requirement that a second factor be provided. As such, the symmetric keys used by authenticators SHALL be strongly protected against compromise.

When a multi-factor OTP authenticator is being associated with a subscriber account, the verifier (or associated CSP) SHALL obtain secrets required to duplicate the authenticator output from the authenticator source (typically its manufacturer) using approved cryptography. The verifier or CSP SHALL also obtain an assertion from the authenticator source that the authenticator is a multi-factor device. In the absence of a trusted assertion that it is a multi-factor device, the verifier SHALL treat it the authenticator as single factor, in accordance with section 5.1.4.

The verifier SHALL use approved encryption and SHALL utilize an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and man-in-the-middle attacks. Time-based one-time passwords SHALL have a lifetime of less than 2 minutes.

If the authenticator output or activation secret has less than 64 bits of entropy, the verifier 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. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on number of successive authentication failures.

5.1.6. Single Factor Cryptographic Software

5.1.6.1. Single Factor Cryptographic Software Authenticators

Single factor software cryptographic authenticators encapsulate a secret key that is unique to the authenticator. The key SHALL be stored in the most secure storage available on the device (e.g., keychain storage, trusted platform module, or trusted execution environment if available). 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.

5.1.6.2. Single Factor Cryptographic Software Verifiers

The requirements for a single factor cryptographic software verifier are identical to those for a single factor cryptographic device verifier, described in Section 5.1.7.2.

5.1.7. Single Factor Cryptographic Devices

5.1.7.1. Single Factor Cryptographic Device Authenticators

Single-factor cryptographic device authenticators encapsulate a secret key that is unique to the device and SHALL NOT be exportable (removed from the device). They operate by signing a challenge nonce, usually presented through a direct computer interface such as a USB port. Although cryptographic devices contain software, they differ from cryptographic software authenticators by the fact that all embedded software is under control of the CSP (or other issuer), and that the entire authenticator is subject to any applicable FIPS 140 requirements at the AAL being authenticated.

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of [SP 800-131A] (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

Single-factor cryptographic device authenticators SHOULD require a physical input such as the pressing of a button in order to operate. This provides defense against unintended operation of the device, which might occur if the device to which it is connected is compromised.

5.1.7.2. Single Factor Cryptographic Device Verifiers

Single-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device. The authenticator output is highly dependent on the specific cryptographic device and protocol, but it is generally some type of signed message.

The verifier has either symmetric or asymmetric cryptographic keys corresponding to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be strongly protected against unauthorized disclosure.

The challenge nonce SHALL be at least 64 bits in length, and SHALL either be unique over the lifetime of the authenticator or statistically unique (generated using an approved random bit generator).

5.1.8. Multi-Factor Cryptographic Software

5.1.8.1. Multi-Factor Cryptographic Software Authenticators

Multi-factor software cryptographic authenticators encapsulate a secret key that is unique to the authenticator and is accessible only through the input of an additional factor, either a memorized secret or a biometric. The key SHOULD be stored in the most secure storage available on the device (e.g., keychain storage, trusted platform module, or trusted execution environment if available).

Each authentication operation using the authenticator SHALL require the input of the additional factor.

Any memorized secret used by the authenticator for activation SHALL be at least 6 decimal digits (approximately 20 bits) in length or of equivalent complexity and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, and SHALL include limits on number of successive authentication failures.

The unencrypted key and activation secret or biometric sample (and any biometric data derived from the biometric sample such as a probe produced through signal processing) SHALL be erased from memory immediately after an authentication transaction has taken place.

5.1.8.2. Multi-Factor Cryptographic Software Verifiers

The requirements for a multi-factor cryptographic software verifier are identical to those for a multi-factor cryptographic device verifier, described in Section 5.1.9.2.

5.1.9. Multi-Factor Cryptographic Devices

5.1.9.1. Multi-Factor Cryptographic Device Authenticators

Multi-factor cryptographic device authenticators use tamper-resistant hardware to encapsulate a secret key that is unique to the authenticator and is accessible only through the input of an additional factor, either a memorized secret or a biometric. Although cryptographic devices contain software, they differ from cryptographic software authenticators by the fact that all embedded software is under control of the CSP (or other issuer), and that the entire authenticator is subject to any applicable FIPS 140 requirements at the AAL being authenticated.

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of [SP 800-131A] (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

Each authentication operation using the authenticator SHOULD require the input of the additional factor. Input of the additional factor MAY be accomplished via either direct input on the device or via a hardware connection (e.g., USB or smartcard).

Any memorized secret used by the authenticator for activation SHALL be at least 6 decimal digits (approximately 20 bits) in length or of equivalent complexity and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, and SHALL include limits on number of successive authentication failures.

The unencrypted key and activation secret or biometric sample (and any biometric data derived from the biometric sample such as a probe produced through signal processing) SHALL be erased from memory immediately after an authentication transaction has taken place.

5.1.9.2. Multi-Factor Cryptographic Device Verifiers

Multi-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device and activation factor.

The verifier has either symmetric or asymmetric cryptographic keys corresponding to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be strongly protected against unauthorized disclosure.

The challenge nonce SHALL be at least 64 bits in length, and SHALL either be unique over the lifetime of the authenticator or statistically unique (generated using an approved random bit generator). The verification operation SHALL use approved cryptography.

5.2. General Authenticator Requirements

5.2.1. Physical Authenticators

CSPs SHALL provide subscriber instructions on how to appropriately protect the authenticator against theft or loss. The CSP SHALL provide a mechanism to revoke or suspend the authenticator immediately upon notification from subscriber that loss or theft of the authenticator is suspected.

5.2.2. Rate Limiting (Throttling)

cf. 800-63-2 sec 8.2.3, p.75

When the authenticator output or activation secret does not have sufficient entropy, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL effectively limit online attackers to 100 consecutive failed attempts on a single account in any 30 day period.

Additional techniques MAY be used to prioritize authentication attempts that are likely to come from the subscriber over those that are more likely to come from an attacker:

• Requiring the claimant to complete a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) before attempting authentication

• Requiring the claimant to wait for a short period of time (anything from 30 seconds to an hour, depending on how close the system is to its maximum allowance for failed attempts) before attempting Authentication following a failed attempt

• Only accepting authentication requests from a white list of IP addresses at which the subscriber has been successfully authenticated before

• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms.

Since these measures often create user inconvenience, the verifier SHOULD allow a certain number of failed authentication attempts before employing the above techniques.

When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts from the same IP address.

5.2.3. Use of Biometrics

For a variety of reasons, this document supports only limited use of biometrics for authentication. These include:

• Biometric False Match Rates (FMR) and False Non-Match Rates (FNMR) do not provide confidence in the authentication of the subscriber by themselves. In addition, FMR and FNMR do not account for spoofing attacks.
• Biometric matching is probabilistic, whereas the other authentication factors are deterministic.
• Biometric template protection schemes provide a method for revoking biometric credentials that are comparable to other authentication factors (e.g., PKI certificates and passwords). However, the availability of such solutions is limited, and standards for testing these methods are under development.
• Biometric characteristics do not constitute secrets. They can be obtained online or by taking a picture of someone with a camera phone (e.g. facial images) with or without their knowledge, lifted from through objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns for blue eyes). While presentation attack detection (PAD) technologies such as liveness detection can mitigate the risk of these types of attacks, additional trust in the sensor is required to ensure that PAD is operating properly in accordance with the needs of the CSP and the subscriber.

Therefore, the use of biometrics for authentication is supported, with the following requirements and guidelines:

Biometrics SHALL be used with another authentication factor (something you know or something you have).

Empirical testing of the biometric system to be deployed SHALL demonstrate an equal error rate of 1 in 1000 or better with respect to matching performance. The biometric system SHALL operate with a false match rate of 1 in 1000 or better.

When the biometric sensor and subsequent processing are not part of an integral unit that resists replacement of the sensor, the sensor (or endpoint with which it is an integral unit that resists sensor replacement) SHALL demonstrate that it is a certified or qualified sensor meeting these requirements by authenticating itself to the processing element.

The biometric system SHOULD implement presentation attack protection (PAD). Testing of the biometric system to be deployed SHOULD demonstrate at least 90% resistance to presentation attacks for each relevant attack type (aka species), where resistance is defined as the number of thwarted presentation attacks divided by the number of trial presentation attacks.

Note: Presentation attack detection is being considered as a mandatory requirement in future editions of this guideline.

The biometric system SHALL allow no more than 3 consecutive failed authentication attempts, or 10 consecutive failed attempts if presentation attack detection meeting the above requirements is implemented. Once that limit has been reached, the claimant SHALL be required to use a different authenticator or to activate their authenticator with a different factor such as a memorized secret.

Biometric matching SHOULD be performed locally on claimant’s device or MAY be performed at a central verifier.

If matching is performed centrally:

• Use of the biometric SHALL be bound tightly to a single, specific device that is identified using approved cryptography.
• Biometric revocation, referred to as biometric template protection in ISO/IEC 24745, SHALL be implemented.
• An authenticated protected channel between sensor (or integral unit containing endpoint and sensor that resists sensor replacement) and central verifier SHALL be established, and the sensor authenticated, prior to capturing the biometric sample from the claimant.
• All transmission of biometrics shall be over the authenticated protected channel.

Biometric samples collected in the authentication process MAY be used to train matching algorithms or, with user consent, for other research purposes. Biometric samples (and any biometric data derived from the biometric sample such as a probe produced through signal processing) SHALL be erased from memory immediately after a password has been generated.

Biometrics are also used in some cases to prevent repudiation of registration and to verify that the same individual participates in all phases of the registration process as described in SP 800-63A.

5.2.4. Attestation

Authenticators that are directly connected to or embedded in endpoints MAY convey attestation information to the verifier as part of the authentication protocol such as:

• The provenance, health, and/or integrity of the authenticator and/or endpoint
• Security features of the authenticator
• Security and performance characteristics of biometric sensor(s)
• Sensor modality

If this attestation is signed, it SHALL be signed using a digital signature that provides at least the minimum security strength specified in the latest revision of [SP 800-131A] (112 bits as of the date of this publication). Attestation information MAY be used as part of a risk-based authentication decision.

When federated authentication is being performed as described in SP 800-63C, the verifier SHOULD include any such attestation information in the assertion it provides to the relying party.

5.2.5. Verifier impersonation resistance

Verifier impersonation attacks, sometimes referred to as “phishing attacks”, refer to attempts by fraudulent verifiers and relying parties to fool an unwary claimant into authenticating to an impostor website. In previous editions of SP 800-63, protocols that are resistant to verifier impersonation attacks were also referred to as “strongly man-in-the-middle resistant”.

Authentication protocols that are verifier impersonation resistant SHALL authenticate the verifier and either:

1. Strongly and irreversibly bind the authenticator output to the public key of the certificate presented by the verifier to which it is sent, or to that verifier’s authenticated hostname or domain name; or

2. Determine whether the verifier’s authenticated hostname or domain name is on a list of trusted verifiers, and release the authenticator output only to a verifier on that list.

One example of the former class of verifier impersonation resistant authentication protocols is client-authenticated TLS, because the client signs the authenticator output along with earlier messages from the protocol that are unique to the particular TLS connection being negotiated. Other protocols that MAY be used are techniques that irreversibly include the verifier’s hostname or domain in the generation of the authenticator output, making that authenticator output unusable by a fraudulent verifier (the attacker) if proxied to the intended verifier.

The latter class of verifier impersonation resistant protocols relies on access control to release the authenticator output only to trusted verifiers.

In contrast, authenticators that involve the manual entry of an authenticator output, such as out of band and one-time password authenticators, SHALL NOT be considered verifier impersonation resistant because they assume the vigilance of the claimant to determine that they are communicating with the intended verifier.

5.2.6. Verifier-CSP commmunications

In situations where the verifier and CSP are separate entities (as shown by the dotted line in SP 800-63-3 Figure 4-1), communications between the verifier and CSP SHALL occur through a mutually-authenticated secure channel (such as a client-authenticated TLS connection) using approved cryptography.

6. Authenticator Lifecycle Management

During the lifecycle of an authenticator bound to a subscriber’s identity, a number of events can occur that affect the use of that authenticator. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions that SHALL be taken in response to those events.

6.1. Authenticator binding

Authenticators MAY be issued (provided) by a CSP as part of a process such as enrollment; in other cases, the subscriber MAY provide their own, such as software or hardware cryptographic modules. For this reason, this guideline refers to the binding of an authenticator rather than the issuance, but this does not exclude the possibility that an authenticator is issued as well.

Throughout the online identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with the identity. The CSP or verifier SHALL also maintain the information required for throttling authentication attempts when required, as described in section 5.2.2.

The record created by the CSP SHALL contain the date and time the authenticator was bound to the account and SHOULD include information about the binding, such as the IP address or other device identifier associated with the enrollment. If available, the record SHOULD also contain information about unsuccessful authentications attempted with the authenticator.

6.1.1. Enrollment

The following requirements apply when an authenticator is bound to an identity as a result of a successful identity proofing transaction, as described in SP 800-63A.

At IAL 2, the CSP SHALL bind at least one, and SHOULD bind at least two, authenticators to the subscriber’s online identity. Binding of multiple authenticators is preferred in order to recover from loss or theft of their primary authenticator. While at IAL 1 all identifying information is self-asserted, creation of online material or an online reputation makes it undesirable to lose control of an account as result of the loss of an authenticator. The second authenticator makes it possible to securely recover from that situation.

At IAL 2 and above, identifying information is associated with the online identity and the subscriber has undergone an identity proofing process as described in SP 800-63A. As a result, authenticators at the same AAL as the desired IAL SHALL be bound to the account. For example, if the subscriber has successfully completed proofing at IAL 2, AAL 2 or 3 authenticators are appropriate to bind to the IAL 2 identity. As above, the availability of additional authenticators provides backup methods of authentication if an authenticator is damaged, lost, or stolen.

Enrollment and binding MAY be broken up into a number of separate physical encounters or electronic transactions. (Two electronic transactions are considered to be separate if they are not part of the same protected session.) In these cases, the following methods SHALL be used to ensure that the same party acts as Applicant throughout the processes:

1. For remote transactions:
   1. The applicant SHALL identify himself/herself in each new transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or postal address of record.
   2. Long-term authenticator secrets SHALL only be issued to the Applicant within a protected session.
2. For physical transactions:
   1. The applicant SHALL identify himself/herself in person by either using a secret as described above, or through the use of a biometric that was recorded during a prior encounter.
   2. Temporary secrets SHALL not be reused.
   3. If the CSP issues long-term authenticator secrets during a physical transaction, then they SHALL be loaded locally onto a physical device that is issued in person to the applicant or delivered in a manner that confirms the address of record.

6.1.2. Post-Enrollment Binding

6.1.2.1. Binding of additional authenticator at existing AAL

Subscribers SHOULD be encouraged to maintain at least two valid authenticators of each factor they will be using. For example, a subscriber that usually uses a one-time OTP device as a physical authenticator MAY also be issued a number of look-up secret authenticators, or register a device for out-of-band authentication, in case the physical authenticator is lost, stolen, or damaged.

Accordingly, CSPs SHOULD permit the binding of additional authenticators to a subscriber’s account. Before adding the new authenticator, the CSP SHALL first require the subscriber to authenticate at the AAL (or a higher AAL) at which the new authenticator will be used. When an authenticator is added, the CSP SHOULD send a notification to the subscriber. The CSP MAY limit the number of authenticators that may be bound in this manner.

6.1.2.2. Adding an additional factor to a one-factor account

If the subscriber’s account has only one authentication factor bound to it (at IAL 1/AAL 1), and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the account be upgraded to AAL 2 (but still at IAL 1). Once this has been done, the CSP SHALL no longer permit the subscriber to use single-factor authentication.

Prior to binding the new authenticator, the CSP SHALL first require the subscriber to authenticate at AAL 1. The CSP SHOULD send a notification of the event to the subscriber.

6.1.2.3. Replacement of lost authentication factor

As a last resort, if a subscriber loses all authenticators of a factor necessary to complete multi-factor authentication and has been identity proofed at IAL 2 or 3, that subscriber SHALL repeat the identity proofing process. An abbreviated proofing process, confirming the binding of the claimant to previously-supplied evidence MAY be used if the CSP has retained the evidence from the original proofing process pursuant to a privacy risk assessment as described in SP 800-63A section 4.2. The CSP SHALL require the claimant to authenticate using an authenticator of the remaining factor (if any) to confirm binding to the existing identity. Reestablishment of authentication factors at IAL 3 SHALL be done in person and SHALL verify the biometric collected during the proofing process.

The CSP SHOULD send a notification of the event to the subscriber; this MAY be the same notice as is required as part of the proofing process.

6.1.3. Binding to a subscriber-provided authenticator

A subscriber MAY already possess authenticators suitable for authentication at a particular AAL. For example, he or she MAY have a two-factor authenticator from a social network provider, considered AAL2 and IAL1, and would like to use those credentials at a relying party that requires IAL2.

CSPs SHOULD, where practical, accommodate the use of subscriber-provided authenticators in order to relieve the burden to the subscriber of managing a large number of authenticators. Binding of these authenticators SHALL be done as described in section 6.1.2.1.

6.1.4. Renewal

The CSP SHOULD bind an updated authenticator an appropriate amount of time in advance of an existing authenticator’s expiration. The process for this SHOULD conform closely to the initial authenticator issuance process (e.g., confirming address of record, etc.). Following successful use of the new authenticator, the CSP MAY revoke the authenticator that it is replacing.

6.2. Loss, Theft, Damage, and Unauthorized Duplication

Loss, theft, damage to and unauthorized duplication of an authenticator are handled similarly, because in most cases one must assume that a lost authenticator has potentially been stolen or recovered by someone that is not the legitimate claimant of the authenticator. Damaged or malfunctioning authenticators SHALL be treated in a similar manner to protect against any possibility of extraction of the authenticator secret. One notable exception is when a memorized secret is forgotten without other indication of having been compromised (duplicated by an attacker).

To facilitate secure reporting of loss or theft of or damage to an authenticator, the CSP SHOULD provide the subscriber a method to authenticate to the CSP using a backup authenticator; either a memorized secret or a physical authenticator MAY be used for this purpose (only one authentication factor is required for this purpose). Alternatively, the subscriber MAY establish an authenticated protected channel to the CSP and verify information collected during the proofing process. Alternatively, the CSP MAY verify an address of record (email, telephone, or postal) and suspend authenticator(s) reported to have been compromised. The suspension SHALL be reversible if the subscriber successfully authenticates to the CSP and requests reactivation of an authenticator suspended in this manner.

6.3. Expiration

CSPs MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the CSP as soon as practical after expiration or receipt of a renewed authenticator.

6.4. Revocation and Termination

Revocation of an authenticator (sometimes referred to as termination, especially in the context of PIV credentials) refers to removal of the binding between an authenticator and a credential the CSP maintains. CSPs SHALL revoke the binding of authenticators promptly when an online identity ceases to exist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requested by the subscriber, or when the CSP determines that the subscriber no longer meets its eligibility requirements.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing certified attributes signed by the CSP as soon as practical after revocation or termination takes place.

Further requirements on the termination of PIV credentials are found in [FIPS 201].

7. Session Management

Once an authentication event has taken place, it is often desirable to allow the user to continue using the application across multiple subsequent interactions without requiring the user to repeat the authentication event every time. This requirement is particularly true for federation scenarios (described in volume C), where the authentication event necessarily involves several components and actors coordinating across a network.

To facilitate this behavior, a session MAY be started in response to an authentication event, and such a session SHALL continue until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or other means. The session MAY be continued through a reauthentication event (described in section 7.2), wherein the user repeats some or all of the initial authentication event, thereby asserting their presence again.

Session management is preferable over continuous presentation of credentials as the usability requirements of such continuous presentation would incentivize workarounds such as cached unlocking credentials, negating the freshness of the authentication event in the first place.

7.1. Session Bindings

A session occurs between the software that a subscriber is running, such as a browser, application, or operating system (the session subject), and the RP or CSP that the subscriber is accessing (the session host). A session secret SHALL be shared between the subscriber’s software and the service being accessed. This secret binds the two ends of the session, allowing the user to continue using the service over time. The secret MAY be presented directly by the user’s software (a bearer secret) or possession of the secret MAY be proven using a cryptographic mechanism (a proof of possession secret).

The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation; a session MAY be considered at a lower AAL than the authentication event and SHALL NOT be considered at a higher AAL than the authentication event.

Secrets used for session binding:

• SHALL be generated by the session host during an interaction, typically immediately following user authentication
• SHALL be generated by an approved random bit generator and contain at least 64 bits of entropy
• SHALL be erased or invalidated by the session subject when the user logs out
• SHOULD be erased on the user endpoint when the user logs out or when the secret is deemed to have expired
• SHOULD not be placed in insecure locations such as HTML5 Local Storage due to the potential exposure of local storage to cross-site scripting (XSS) attacks
• SHALL be sent to and received from the device using an authenticated protected channel
• SHALL time out and not be accepted after the times specified in section 4.1.4, 4.2.4, and 4.3.4 (depending on AAL)
• SHALL not be available to insecure communications between the host and user endpoint; authenticated sessions SHALL not fall back to an insecure transport such as from https to http following authentication.

URLs or POST content SHALL contain a session identifier that SHALL be verified by the relying party to ensure that actions taken outside the session do not affect the protected session.

There are several different mechanisms for managing a session over time. The following sections give three examples, along with additional requirements and considerations particular to each example technology.

7.1.1. Browser Cookies

Browser cookies are the predominant mechanism by which a session will be created and tracked for a user accessing a service.

Cookies:

• SHALL be tagged to be accessible on secure (HTTPS) sessions only
• SHALL be accessible to the minimum practical set of hostnames and paths
• SHOULD be tagged to be inaccessible via JavaScript (HttpOnly)
• SHOULD be tagged to expire at or soon after the validity period of the session (This requirement is intended to limit the accumulation of cookies, but SHALL NOT be depended upon to enforce session timeouts.)

7.1.2. OAuth Tokens

An OAuth access token is be used to allow an application to access a set of services on behalf of a user following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP to indicate the presence of the user, in the absence of other signals. The OAuth access token (and any associated refresh tokens) MAY be valid long after the authentication session has ended and the user has left the application in question.

7.1.3. Device Identification

Other methods of secure device identification, including but not limited to mutual TLS, token binding, or other mechanisms, MAY be used to enact a session between a user and a service.

7.2. Reauthentication

A session SHALL NOT be extended past the guidelines in sections 4.1.4, 4.2.4, and 4.3.4 (depending on AAL) based on presentation of the session secret alone.

When a session is terminated due to a time-out or other action, the user MAY reauthenticate using their primary authentication mechanism or an appropriate subset thereof, depending on the AAL.

AAL	Requirement
1	Presentation of any one factor
2	Presentation of a memorized secret or biometric
3	Presentation of all factors

Note: At AAL 2, a memorized secret or biometric and not a physical authenticator is required because the session secret is something you have, and an additional authentication factor is required to continue the session.

7.2.1 Reauthentication from a federation or assertion

When using a federation protocol to connect the CSP and RP, special consideration needs to be made for session management and reauthentication. Both the CSP and RP employ separate session management technologies, and there SHALL NOT be any assumption of correlation between these sessions. Consequently, when a session expires at an RP and reauthentication is required by the RP, it is entirely possible that the session at the CSP is not expired and a new assertion could be generated from this session at the CSP without reauthenticating the user. Therefore, an RP requiring a reauthentication through a federation protocol SHALL indicate a minimum acceptable authentication age to the CSP (if possible within the protocol), and the CSP SHALL honor this request (if possible). The CSP in all cases SHALL communicate the primary authentication event time to the RP to allow the RP to decide if the assertion is sufficient for reauthentication or not.

8. Threats and Security Considerations

This section is non-normative.

8.1. Authenticator Threats

An attacker who can gain control of an authenticator will often be able to masquerade as the authenticator’s owner. Threats to authenticators can be categorized based on attacks on the types of authentication factors that comprise the authenticator:

• Something you have may be lost, damaged, stolen from the owner or cloned by an attacker. For example, an attacker who gains access to the owner’s computer might copy a software authenticator. A hardware authenticator might be stolen, tampered with, or duplicated.

• Something you know may be disclosed to an attacker. The attacker might guess a memorized secret. Where the authenticator is a shared secret, the attacker could gain access to the CSP or verifier and obtain the secret value or perform a dictionary attack on a hash of that value. An attacker may observe the entry of a PIN or passcode, find a written record or journal entry of a PIN or passcode, or may install malicious software (e.g., a keyboard logger) to capture the secret. Additionally, an attacker may determine the secret through offline attacks on a hashed password database maintained by the verifier.

• Something you are may be replicated. An attacker may obtain a copy of the subscriber’s fingerprint and construct a replica - assuming that the biometric system(s) employed do not block such attacks by employing robust liveness detection techniques.

• Out of band secrets may be intercepted. An attacker may receive a challenge or response by eavesdropping on the primary or secondary communications channel. The attacker might then authenticate their own channel or save the message for later replay.

This document assumes that the subscriber is not colluding with the attacker who is attempting to falsely authenticate to the verifier. With this assumption in mind, the threats to the authenticator(s) used for e-authentication are listed in Table 8-1, along with some examples.

Authenticator Threats/Attacks	Description	Examples
Theft	A physical authenticator is stolen by an Attacker.	A hardware cryptographic device is stolen.
		A One-Time Password device is stolen.
		A look-up secret authenticator is stolen.
		A cell phone is stolen.
Duplication	The subscriber’s authenticator has been copied with or without their knowledge.	Passwords written on paper are disclosed.
		Passwords stored in an electronic file are copied.
		Software PKI authenticator (private key) copied.
		Look-up secret authenticator copied.
Eavesdropping	The authenticator secret or authenticator output is revealed to the attacker as the subscriber is authenticating.	Memorized secrets are obtained by watching keyboard entry.
		Memorized secrets or authenticator outputs are intercepted by keystroke logging software.
		A PIN is captured from PIN pad device.
		A hashed password is obtained and used by an attacker for another authentication (pass-the-hash attack)
	An out of band secret is intercepted by the attacker by compromising the communication channel.	An out of band secret is transmitted via unencrypted wifi and received by the attacker.
Offline cracking	The authenticator is exposed using analytical methods outside the authentication mechanism.	A software PKI authenticator is subjected to dictionary attack to identify the correct password to use to decrypt the private key.
Side channel attack	The authenticator secret is exposed using physical characteristics of the authenticator.	A key is extracted by differential power analysis on a hardware cryptographic authenticator.
		A cryptographic authenticator secret is extracted by analysis of the response time of the authenticator over a number of attempts.
Phishing or pharming	The authenticator output is captured by fooling the subscriber into thinking the attacker is a verifier or RP.	A password is revealed by subscriber to a website impersonating the verifier.
		A memorized secret is revealed by a bank subscriber in response to an email inquiry from a phisher pretending to represent the bank.
		A memorized secret is revealed by the subscriber at a bogus verifier website reached through DNS spoofing.
Social engineering	The attacker establishes a level of trust with a subscriber in order to convince the subscriber to reveal his or her authenticator secret or authenticator output.	A memorized secret is revealed by the subscriber to an officemate asking for the password on behalf of the subscriber’s boss.
		A memorized secret is revealed by a subscriber in a telephone inquiry from an attacker masquerading as a system administrator.
		An out of band secret sent via SMS is received by an attacker who has convinced the mobile operator to redirect the victim’s mobile phone to the attacker.
Online guessing	The attacker connects to the verifier online and attempts to guess a valid authenticator output in the context of that verifier.	Online dictionary attacks are used to guess memorized secrets.
		Online guessing is used to guess authenticator outputs for a one-time password device registered to a legitimate claimant.
Endpoint compromise	Malicious code on the endpoint proxies remote access to a connected authenticator without user consent.	A cryptographic authenticator connected to the endpoint is used to authenticate remote attackers.
	Malicious code on the endpoint causes authentication to other than the intended verifier.	Authentication is performed on behalf of an attacker rather than the subscriber.
		A malicious app on the endpoint reads an out of band secret sent via SMS; the attacker uses the secret to authenticate.
	Malicious code on the endpoint compromises a multi-factor software cryptographic authenticator.	Malicious code proxies authentication or exports authenticator keys from the endpoint.

8.2. Threat Mitigation Strategies

Related mechanisms that assist in mitigating the threats identified above are summarized in Table 8-2.

Authenticator Threat/Attack	Threat Mitigation Mechanisms
Theft	Use multi-factor authenticators which need to be activated through a memorized secret or biometric.
Duplication	Use authenticators from which it is difficult to extract and duplicate long-term authentication secrets.
Eavesdropping	Ensure the security of the endpoint, especially with respect to freedom from malware such as key loggers, prior to use.
	Maintain situational awareness when entering memorized secrets and one-time passwords to ensure that they cannot be observed by others.
	Authenticate over authenticated protected channels (observe lock icon in browser window, for example)
	Use authentication protocols that are resistant to replay attacks such as pass-the-hash
Offline cracking	Use an authenticator with a high entropy authenticator secret.
	Store memorized secrets in a salted, hashed form to raise the cost of dictionary attacks; use a keyed hash.
Side channel attack	Use authenticator algorithms that are designed to maintain constant power consumption and timing regardless of secret values.
Phishing or pharming	Use authenticators that provide verifier impersonation resistance.
	Be alert for unexpected hostnames in URLs.
	Do not click on links in email messages; instead, enter the URL manually or through a trusted bookmark.
Social engineering	Do not reveal authentication secrets to others, regardless of their story.
	Avoid use of authenticators that present a risk of social engineering of third parties such as customer service agents.
Online guessing	Use authenticators that generate high entropy output.
	Use an authenticator that locks up after a number of repeated failed activation attempts.
Endpoint compromise	Use hardware authenticators that require physical action by the subscriber.
	Provide secure display of identity of verifier and relying party.
	Maintain software-based keys in restricted-access storage.

There are several other strategies that may be applied to mitigate the threats described in Table 5:

• Multiple factors make successful attacks more difficult to accomplish. If an attacker needs to both steal a cryptographic authenticator and guess a memorized secret, then the work to discover both factors may be too high.

• Physical security mechanisms may be employed to protect a stolen authenticator from duplication. Physical security mechanisms can provide tamper evidence, detection, and response.

• Requiring the use of long memorized secrets that don’t appear in common dictionaries may force attackers to try every possible value.

• System and network security controls may be employed to prevent an attacker from gaining access to a system or installing malicious software.

• Periodic training may be performed to ensure subscribers understand when and how to report compromise (or suspicion of compromise) or otherwise recognize patterns of behavior that may signify an attacker attempting to compromise the authentication process.

• Out of band techniques may be employed to verify proof of possession of registered devices (e.g., cell phones).

8.3. Authenticator Recovery

The weak point in many authentication mechanisms is the process followed when a subscriber loses control of one or more authenticators and needs to replace them. In many cases, the options remaining available to authenticate the subscriber are limited, and economic concerns (cost of maintaining call centers, etc.) motivate the use of inexpensive, and frequently less secure, backup authentication methods. To the extent that authenticator recovery is human-assisted, there is also the risk of social engineering attacks.

In order to maintain the integrity of the authentication factors, it is essential that it not be possible to leverage an authentication involving one factor to obtain an authenticator of a different factor. For example, a memorized secret must not be usable to obtain a new list of look-up secrets.

8.4. Session Attacks

The above discussion focuses on threats to the authentication event itself, but hijacking attacks on the session following an authentication event can have similar security impacts. The session management guidelines in Section 7 are essential to maintain session integrity against attacks, such as cross-site scripting (XSS). In addition, it is important to sanitize all information to be displayed [OWASP-XSS-prevention] to ensure that it does not contain executable content. These guidelines also recommend that session secrets be made inaccessible to mobile code in order to provide extra protection against exfiltration of session secrets should it be possible to inject malicious mobile code.

Another post-authentication threat, cross-site request forgery (CSRF), takes advantage of users’ tendency to have multiple sessions active at the same time. It is important to embed and verify a session identifier into web requests to prevent the ability for a valid URL or request to be unintentially or maliciously activated.

9. Privacy Considerations

These privacy considerations supplement the guidance in section 4. This section is informative.

9.1. Privacy Risk Assessment

Subsections 4.1.6, 4.2.6 and 4.3.6 require the CSP to conduct a privacy risk assessment for records retention. Such a privacy risk assessment would include:

1. The likelihood that the records retention could create a problem for the subscriber such as invasiveness or unauthorized access to the information
2. The impact if a problem did occur

CSPs should be able to reasonably justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk; and sharing the risk. The use of subscriber consent is a form of sharing the risk, and therefore appropriate for use only when a subscriber could reasonably be expected to have the capacity to assess and accept the shared risk.

9.2. Privacy Controls

Section 4.4 encourages CSPs to employ appropriately tailored privacy controls. NIST [SP 800-53] provides a set of privacy controls for CSPs to consider when deploying authentication mechanisms. These controls cover notices, redress and other important considerations for successful and trustworthy deployments.

9.3. Use Limitation

Section 4.4 does not permit the CSP to use information about authenticators that is collected and maintained in the authentication process for any purpose other than authentication or to comply with law or legal process, unless the CSP provides clear notice and obtains consent from the subscriber for additional uses. Care should be taken to ensure that use of such information is limited to its original purpose for collection. Consult your Senior Agency Official for Privacy (SAOP) if there are questions about whether proposed agency uses fall within this scope. As stated in Section 4.4, acceptance by the subscriber of additional uses SHALL NOT be a condition of providing authentication services.

9.4. Agency Specific Privacy Compliance

Section 4.4 covers specific compliance obligations for federal CSPs. It is critical to involve your agency’s SAOP in the earliest stages of digital authentication system development to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the collection of Personally Identifiable Information (PII) to issue or maintain authenticators triggers the Privacy Act of 1974 [Privacy Act] or the E-Government Act of 2002 [E-Gov] requirement to conduct a Privacy Impact Assessment (PIA). For example, with respect to centralized maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of attributes/PII necessary for authentication. The SAOP can similarly assist the agency in determining whether a PIA is required.

These considerations should not be read as a requirement to develop a Privacy Act System of Records Notice (SORN) or PIA for authentication alone; in many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the program or benefit the agency is establishing online access to.

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component so as to advise appropriately on what compliance requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

10. Usability Considerations

This section is informative.

ISO/IEC 9241-11 defines usability as: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. This definition focuses on users, goals, and context of use as key elements necessary for achieving effectiveness, efficiency and satisfaction. A holistic approach considering these key elements is necessary to achieve usability.

Users’ goals for accessing an information system are to perform their intended tasks. Authentication is not a user’s primary task, but an enabling task standing between the users and their goals. Authentication should be designed and implemented to make it easy for users to do the right thing, hard to do the wrong thing, and easy to recover when something goes wrong.

Organizations must be cognizant of the overall implications of their stakeholders entire digital authentication ecosystem. Many times, users employ one or more authenticators, each for different RPs. Users struggle to remember passwords, to carry multiple authentication devices, and to remember which authenticator goes with which RP. It is critical to evaluate the usability of authentication, since poor usability often results in user coping mechanisms and unintended user work-arounds, which can ultimately degrade the intended security controls.

In order to address users’ authentication needs and organizations’ security goals, organizations should assess the impact of usability across their digital systems, as part of the risk assessment when deciding on the Authenticator Assurance Level (AAL) requirements. If authenticators with a higher AAL offer better usability, users should be allowed to use them for lower AAL applications. For example, rather than forcing users to manage many passwords, allow users to use their favorite authenticator across the organization’s applications. Users should be able to choose their authenticator, and in some instances, may choose to only have to manage one authenticator for their digital authentication needs. For example, this may be achieved by adopting identity federation (see NIST SP 800-63C, Federation and Assertions). For the selection of an authenticator, only by considering the combination of users, their goals, and context of use with the authenticator and the security risk assessment can usability and security be achieved in tandem. The current section takes this holistic view in applying usability principles to authenticators across their lifecycle.

ASSUMPTIONS

In this section, the term “users” means “Claimants” or “Subscribers.” This section describes guidelines and considerations from the end-users’ perspective, as usability guidelines can only be written from the end-users’ perspective.

Accessibility and usability differ significantly; therefore, accessibility is out of scope for this section. However, organizations should obviously address accessibility in their implementation plans.

10.1. Usability Considerations by Authenticator Type

For the selection and implementation of an authentication system, usability should be considered across the entire lifecycle of the selected authenticator(s): enrollment and distribution, typical use, and intermittent events, being mindful of the combination of users, users’ goals, and context of use. This section discusses the usability considerations of authenticators for their typical use and intermittent events, with the goal of raising implementers’ awareness of usability considerations associated with authenticators, and possible implementation options to enhance usability.

In general, a single authenticator option will likely not suffice for the entire population of users. Therefore, whenever possible (depending on the AAL requirements), implementers should provide alternative authenticator types to users and allow users to choose between them depending on their needs. For example, the immediacy of the user’s task, a cost benefit analysis, or unfamiliarity with certain types of authenticators will affect the user’s choice of authenticator. Users generally choose options that incur the least burden or cost at that moment in time. For example, if a user’s task requires immediate access to an information system, a user may prefer to create a new user account and password rather than selecting an authenticator requiring more steps for access to the information system. Alternatively, users may choose to use a federated identity option (approved at the appropriate AAL) if they already have an account with an identity provider. Users may understand some authenticators better than others, and have different levels of trust based on their understanding.

This section focuses on general usability considerations and possible implementations, rather than recommending specific implementation solutions. The possible implementations are provided as examples in order to encourage innovative technological approaches to address specific usability needs. Furthermore, usability considerations and their associated implementation solutions are sensitive to many factors, including context of use; these dependencies prevent a one-size-fits-all solution. For example, in the desktop computing environment, a minimum font size of 12 points may generally work for displaying user facing text, but the same font size of 12 points may force text to scroll off of a small OTP device screen, making it unusable. This is why performing a usability evaluation on the selected authenticator is a critical component of authenticator implementation; evaluations must be conducted with representative users, realistic goals and tasks, and appropriate contexts of use.

Positive user authentication experience is integral to the success of an organizations’ security posture. Therefore, implementers should strive to consider authenticators from the users’ points of view. The overarching goal of usability for authentication is to minimize the authentication burden on users, and to minimize authentication friction (the number of times a user has to authenticate and the steps involved in that authentication, and the amount of information they have to keep track of). For example, one such minimization strategy may be single sign-on (SSO).

10.1.1. Summary of Usability Considerations

Table 10-1 summarizes the usability considerations for typical usage and intermittent events for each of the eight authenticators. The sections following the table provide more detailed discussion on each authenticator. Many of the usability considerations for typical usage apply to the majority of the authenticator types, evidenced by examining the rows. The table highlights common and divergent usability characteristics across the authenticator types. Each column allows readers to easily identify the usability attributes that must be addressed for each authenticator. Depending on users’ goals and the context of use, users may value certain usability attributes more than others. Whenever possible, provide alternative authenticator types to users and allow users to choose between them. It is important to note that multi-factor authenticators (i.e., multi-factor OTP devices, multi-factor cryptographic software, and multi-factor cryptographic devices) also inherit usability considerations of their secondary factor. Since biometrics is only allowed as an activation factor in multi-factor authentication solutions, usability considerations for biometrics are not included in Table 10-1 and are discussed in section 10.2.

10.1.2. Memorized Secret

Typical Usage

Users manually input the memorized secret (commonly referred to as a password or PIN).

Usability considerations for typical usage include:

• Availability of the memorized secret.
  • Users must remember or have their memorized secret readily available. The more items users must remember, the more memory interference will occur, and the greater likelihood of recall failure. For less frequently used passwords, these memory burdens are magnified. Having fewer memorized secrets makes it easier for users to recall the specific memorized secret needed for that particular RP.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues, for example, when users cannot recall their memorized secrets.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of user facing text or text entered by users should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for displaying unmasked secrets.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
    • If possible depending on the size of the device, a minimum font size of 12 points is recommended as long as the text fits for display on the device.
• User experience during entry of memorized secrets.
  • Fields for entry of memorized secrets should support copy and paste functionality. Entry fields should support memorized secrets of at least 64 characters in length; this allows the use of passphrases if desired.
  • An option to display the memorized secret during entry should be offered to the user. Masked text entry is error-prone since users cannot see what they are typing. After the character is displayed for a time sufficient for the user to see the character, then the character can be hidden. It will take longer for users to enter memorized secrets on mobile devices (such as tablets and smartphones) than on traditional desktop computers. Therefore, the masking delay time should take into consideration the device on which the user is entering their memorized secrets.
  • Time allowed for entry of memorized secrets should be adequate to enter the secret, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration. Significant usability implications will arise when users do not know that they have entered their memorized secret incorrectly, preventing users from accomplishing their tasks. However, care should be taken to not provide so much detail that an attacker can glean information rendering the memorized secret vulnerable.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the memorized secrets, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.

Depending on the implementation, form-factor constraints should be considered, as they are particularly problematic if users must enter their memorized secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering memorized secrets on mobile devices.

Intermittent Events

Intermittent events with memorized secrets include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; expired memorized secrets; and revocation. Additionally, users may proactively change their memorized secret.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when memorized secrets are used as a second factor at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When memorized secrets are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions to create and change memorized secrets.
  • Information on how to create and change memorized secrets should be clearly communicated to users.
  • Simplify memorized secret policies by implementing technical defenses, including implementing approved encryption, storing memorized secrets in a form that is resistant to offline attacks, and using blacklists. (see Section 5.1.1 for details).
    • Memorized secret requirements such as minimum length should be clearly communicated to users. Memorized secrets SHALL be at least 8 characters in length as specified in Section 5.1.1.
    • Users should be encouraged to make their memorized secrets as lengthy as they want, and using any characters they like, including spaces. This will allow users to create passphrases to aid memorization. Users should be allowed at least 64 characters in length to support the use of passphrases if desired.
    • No other composition rules (complexity rules) should be imposed (mixtures of different character types, for example) on memorized secrets.
    • Memorized secrets should not be required to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a user requests a change. (Section 5.1.1)
  • When creating memorized secrets, users should not be asked to provide specific types of information (e.g., “What is your favorite food?”, or “What was the name of your first pet?”). These types of questions are difficult for users to remember, especially because information such as personal preferences can change over time.
  • Users should be given clear, meaningful and actionable feedback when chosen passwords are rejected by online services. For example, when a password is rejected because it appears on a “black list” of unacceptable passwords or has been used previously used. The user should be advised that they need to select a different secret because their previous choice was commonly used.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.3. Look-up Secrets

Typical Usage

Users use the authenticator (physical or electronic record) to look up the appropriate secret(s) needed to respond to a prompt from the verifier. For example, a user may be asked by the verifier to provide a specific subset of the numeric or character strings printed on a card in table format.

Usability considerations for typical usage include:

• Availability of the look-up secret authenticator.
  • Users must have their look-up secret authenticators readily in possession when the prompt is delivered.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with look-up secrets.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying both prompts and look-up secrets should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for electronic look-up secrets; serif fonts are recommended for physical look-up secrets.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during entry of look-up secrets.
  • The complexity and size of the prompts should be considered. The larger the subset of secrets a user is prompted to look up, the greater the usability implications are, both the cognitive workload and physical difficulty during entry.
  • Entry of look-up secrets should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of look-up secrets, the legibility considerations for prompts and look-up secrets described above also apply.
  • Time allowed for entry of look-up secrets should be commensurate with the length and complexity of the look-up secrets, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the look-up secrets, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must enter their look-up secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering look up secrets on mobile devices.

Intermittent Events

Intermittent events with look-up secrets include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen look-up secret authenticator; expired look-up secrets; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When look-up secrets are used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.4. Out of Band

Typical Usage

Out of band authentication requires that users have access to a primary and secondary communication channel. Users present the one-time authentication secret (i.e., the out of band secret) received on the secondary channel to the verifier using the primary channel for authentication.

Usability considerations for typical usage include:

• Availability of the out of band device.
  • Users must have their out of band device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with out of band devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying the authentication secret should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for the authentication secret.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during entry of authentication secret.
  • Entry of the authentication secret should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of the authentication secret should be commensurate with the length and complexity of the authentication secret, i.e., the entry screen does not time out prematurely.
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authentication secret, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Users should be notified of the receipt of an authentication secret on a locked device. However, if the out of band device is locked by a user, the user will need to authenticate to the device to access the authentication secret (since the authentication secret cannot be displayed on a locked device screen).
  • Form-factor constraints should be considered if users must enter their authentication secrets on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering authentication secrets on mobile devices.
    • A better usability option is to offer users features that do not require text entry on mobile devices, for example, a single tap on the screen, or a copy feature so users can copy and paste the out of band secrets.
• Providing users such features will be particularly helpful in scenarios where the primary and secondary channels are on the same device. For example, on a smartphone, it is difficult for users to transfer the authentication secret because users must switch back and forth — potentially multiple times —between the out of band application and the primary channel.

Intermittent Events

Intermittent events with out of band devices include, but are not limited to, reauthentication; account lock-out; throttling; authentication secret not received; number of allowed attempts exceeded; damaged, lost, or stolen out of band devices; and revocation. Additionally, users often proactively change or upgrade their mobile devices, which would necessitate updating the linkage between the primary and secondary channels.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When out of band is used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.5. Single Factor OTP Device

Typical Usage

Users access the authenticator output (i.e., one-time password) generated by the single-factor OTP device. The authenticator output is typically displayed on the device and manually input by the user to the verifier, although direct electronic output from the device as input to a computer is also allowed.

Usability considerations for typical usage include:

• Availability of the single-factor OTP device.
  • Users must have their single-factor OTP device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with single-factor OTP devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying authenticator output should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during manual entry of authenticator output.
  • Entry of authenticator output should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of authenticator output should be commensurate with the length and complexity of the authenticator output, i.e., the entry screen does not time out prematurely.
    • Authenticator output should allow at least one minute between changes, but ideally allow users the full 2 minutes as specified in the requirement that the nonce be changed at least once every 2 minutes. Users need adequate time to enter the authenticator output (including looking back and forth between the single-factor OTP device and the entry screen).
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authenticator output, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must enter the authenticator output on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard). Providing larger touch areas will improve usability for entering the authenticator output on mobile devices.
  • If the single-factor OTP device supplies its output via an electronic interface such as USB, this is preferable since users do not have to manually enter the authenticator output. However, if a physical input (such as pressing a button) is required to operate, the location of the USB ports could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer that will be difficult for users to reach.
    • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the single-factor OTP device.

Intermittent Events

Intermittent events with single-factor OTP devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen single-factor OTP devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When single-factor OTP devices are used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.6. Multi-Factor OTP Device

Typical Usage

Users access the authenticator output (i.e., one-time password) generated by the multi-factor OTP device that requires activation through a second authentication factor. The authenticator output is typically displayed on the device and manually input by the user to the verifier, although direct electronic output from the device as input to a computer is also allowed. The second factor of authentication may be achieved through some kind of integral entry pad to enter a memorized secret, an integral biometric (e.g., fingerprint) reader or a direct computer interface (e.g., USB port). Usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Availability of the multi-factor OTP device.
  • Users must have their multi-factor OTP device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with multi-factor OTP devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Legibility of text for displaying authenticator output should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• User experience during manual entry of authenticator output.
  • Entry of authenticator output should not be masked. Masked text entry is error-prone since users cannot see what they are typing. For unmasked text entry of authenticator output, the legibility considerations described above also apply.
  • Time allowed for entry of authenticator output should be commensurate with the length and complexity of the authenticator output, i.e., the entry screen does not time out prematurely.
    • Authenticator output should allow at least one minute between changes, but ideally allow users the full 2 minutes as specified in the requirement that the nonce be changed at least once every 2 minutes. Users need adequate time to enter the authenticator output (including looking back and forth between the multi-factor OTP device and the entry screen).
  • Users should be given clear, meaningful and actionable feedback on entry errors. Such feedback can help reduce user confusion and frustration.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts. The longer and more complex the authenticator output, the greater the likelihood of user entry errors.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Form-factor constraints should be considered if users must unlock the multi-factor OTP device via an integral entry pad; and/or if users must enter the authenticator output on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the integral entry pad and the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the integral entry pad and the onscreen keyboard). Providing larger touch areas will improve usability for unlocking the multi-factor OTP device or entering the authenticator output on mobile devices.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the multi-factor OTP device.

Intermittent Events

Intermittent events with multi-factor OTP devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded (for either factor); damaged, lost, or stolen multi-factor OTP devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when multi-factor OTP devices are used at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When multi-factor OTP devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.7. Single Factor Cryptographic Device

Typical Usage Users prove possession of the single-factor cryptographic device in order to authenticate.

Usability considerations for typical usage include:

• Availability of the single-factor cryptographic device.
  • Users must have their single-factor cryptographic device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with single-factor cryptographic devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • If a physical input (such as pressing a button) is required to operate the single-factor cryptographic device, this could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer that will be difficult for users to reach.
    • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the single-factor cryptographic device.

Intermittent Events

Intermittent events with single-factor cryptographic devices include, but are not limited to, reauthentication; damaged, lost, or stolen single-factor cryptographic devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when single-factor cryptographic devices are used as part of a multi-factor solution at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When single-factor cryptographic devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.8. Multi-Factor Cryptographic Software

Typical Usage

In order to authenticate, users prove possession and control of the cryptographic key stored on disk or some other “soft” media that requires activation. The activation is through the input of a second authentication factor, either a memorized secret or a biometric; usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • All cryptographic keys should be given appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selection among multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
  • Form-factor constraints should be considered if users must unlock the multi-factor cryptographic software on mobile devices (such as tablets and smartphones). Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the onscreen keyboard, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the keyboard).

Intermittent Events

Intermittent events with multi-factor cryptographic software include, but are not limited to, reauthentication; account lock-out; number of allowed attempts exceeded ; non-functional multi-factor cryptographic software; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur.
• When multi-factor cryptographic software is used at AAL 2, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.1.9. Multi-Factor Cryptographic Device

Typical Usage

In order to authenticate, users prove possession of the multi-factor cryptographic device and control of the protected cryptographic key. The device is activated by a second authentication factor, either a memorized secret or a biometric; usability considerations for the additional factor apply as well (see section 10.1.2 for Memorized Secrets and section 10.2 for Biometrics used in Multi-Factor Authenticators).

Usability considerations for typical usage include:

• Availability of the multi-factor cryptographic device.
  • Users must have their multi-factor cryptographic device readily in possession.
  • Whenever possible (depending on the AAL requirements), users should be provided with alternative authentication options. This will allow users to choose their preferred option given their context, goals, and tasks (for example, based on the frequency and immediacy of the task). Alternative authentication options will help address availability issues with multi-factor cryptographic devices.
• Characteristics of user facing text.
  • Any user facing text (e.g., instructions, prompts, notifications, error messages) should be written in plain language for the intended audience. Avoid the use of technical jargon and write for a 6th to 8th grade literacy level.
  • Text legibility should be considered, such as font style, size, color, and contrast with surrounding background. Font legibility is important because users have different levels of visual acuity. Illegible text will contribute to user entry errors. For example, legibility considerations include:
    • The highest contrast is black on white.
    • Sans serif font styles are recommended for authenticator output.
    • Fonts that do not clearly distinguish between easily confusable characters (such as the capital letter “O” and the number zero “0”) are not recommended for use.
• Depending on the implementation, the following are additional usability considerations for implementers:
  • Ideally, the multi-factor cryptographic devices should not require a hardware connection to use. However, if using a hardware connection, the multi-factor cryptographic device should not require users to keep the device connected. Users may forget to disconnect the multi-factor cryptographic device when they are done with it (such as forgetting a smartcard in the smartcard reader and walking away from the computer).
    • Users need to be informed regarding whether the multi-factor cryptographic device is required to stay connected or not.
  • All cryptographic keys should be given appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selection among multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
  • Form-factor constraints should be considered if users must unlock the multi-factor cryptographic device via an integral entry pad. Typing on small devices is significantly more error prone and time consuming than typing on a traditional keyboard for a desktop computer. The smaller the integral entry pad, the more difficult it is to type. This is due to the size of the input mechanism (i.e., a finger) relative to the size of the target (i.e., a single key on the integral entry pad). Providing larger touch areas will improve usability for unlocking the multi-factor cryptographic device.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited which may force users to unplug other USB peripherals in order to use the multi-factor cryptographic device.

Intermittent Events

Intermittent events with multi-factor cryptographic devices include, but are not limited to, reauthentication; account lock-out; throttling; number of allowed attempts exceeded; damaged, lost, or stolen multi-factor cryptographic devices; and revocation.

Usability considerations for intermittent events include:

• To prevent undesired reauthentication events due to user inactivity, users should be prompted to cause activity just before (e.g., 2 minutes before) the inactivity timeout would otherwise occur. This is particularly important when multi-factor cryptographic devices are used at AAL 3 where reauthentication is required at 15 minutes of user inactivity.
• When multi-factor cryptographic devices are used at AAL 2 or AAL 3, users should be prompted and given adequate time (e.g., 1 hour) to save their work prior to the mandatory reauthentication event required at least once every 12 hours, regardless of user activity.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.

10.2. Usability Considerations of Biometrics

For multi-factor authenticators, biometrics can be used as an additional factor. Therefore, in contrast to the previous usability considerations for authenticator types, this section provides only a high-level overview of general usability considerations for biometrics. For a more detailed discussion of biometric usability, see Usability & Biometrics, Ensuring Successful Biometric Systems, http://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184.

Although there are additional biometric modalities, the following three biometric modalities are more commonly used for authentication: fingerprint, face and iris.

Typical Usage

• For all modalities, user familiarity and practice with the device improves performance.
• Device affordances (properties of an object that allow a user to perform an action), feedback, and clear instructions are critical factors to a user’s success with the biometric device. For example, clear instructions describing user actions required for liveness detection should be provided to users.
• Ideally, users should be given the choice to select the modality with which they are most comfortable for their second authentication factor. The user population may be more comfortable with and accepting of some biometric modalities than others. For example, the use of iris technology is not as widely accepted or used as are fingerprints and face.
• User experience with biometrics as an activation factor.
  • Number of allowed attempts should be considered – allow minimum of 10 attempts.
  • Users should be given clear and meaningful feedback on number of remaining allowed attempts. For example, for rate limiting (throttling), users should be informed of the time period they have to wait until next attempt. Such feedback can help reduce user confusion and frustration.
• Fingerprint Usability Considerations:
  • Users must remember which finger(s) they used for initial enrollment.
  • The amount of moisture on the finger(s) affects the sensor’s ability for successful capture.
  • Additional factors also influence fingerprint capture quality, including age, gender, and occupation (e.g., users handling chemicals or who work extensively with their hands may have degraded friction ridges).
• Face Usability Considerations:
  • Users must remember whether they wore any artifacts, such as glasses, during enrollment because it affects facial recognition accuracy.
  • Differences in environmental lighting conditions can affect facial recognition accuracy.
  • Facial poses affect facial recognition accuracy (e.g., smiling versus neutral expression).
• Iris Usability Considerations:
  • Users wearing colored contacts have the potential to affect the iris recognition accuracy.
  • Users who have had eye surgery may need to re-enroll post-surgery.
  • Differences in environmental lighting conditions can affect iris recognition accuracy, especially for certain iris colors.

Intermittent Events

Since biometrics are only permitted as a second factor in a multi-factor authentication scenario, usability considerations for intermittent events with the primary factor still apply. Intermittent events with the use of biometrics include, but are not limited to, the following that may affect recognition accuracy:

• If a user injures his/her enrolled finger(s), fingerprint recognition may not work. Fingerprint authentication will be difficult for users with degraded fingerprints.
• The time elapsed between the time of facial recognition for authentication and the time of the initial enrollment can affect the recognition accuracy as a user’s face changes naturally over time. A user’s weight changes (e.g., weight gain or loss) may also be a factor.
• Iris recognition may not work for people who have had eye surgery unless they re-enroll.

Across all biometric modalities, usability considerations for intermittent events include:

• For all modalities, an alternative authentication method must be available and functioning. In cases where biometrics do not work, users must be allowed to use a memorized secret as an alternative second factor.
• Provisions for technical assistance.
  • Information on how and where to acquire technical assistance should be clearly communicated to users. For example, provide users information such as a link to online self-service feature and a phone number for help desk support. Ideally, sufficient information should be provided to enable users to recover from intermittent events on their own without outside intervention.
  • Users need to be informed regarding factors that may affect the sensitivity of the biometric sensor (e.g., cleanliness of the sensor).

11. References

To be completed

11.1. General References

[OMB M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003, available at: http://www.whitehouse.gov/omb/memoranda/m03-22.html.

[M-04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies, December 16, 2003, available at: https://www.whitehouse.gov/sites/default/files/omb/memoranda/fy04/m04-04.pdf.

[RFC 20] Cerf, V., ASCII format for network interchange, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, http://www.rfc-editor.org/info/rfc20.

[RFC 5246] IETF, The Transport Layer Security (TLS) Protocol Version 1.2, available at https://tools.ietf.org/html/rfc5246/.

[RFC 5280] IETF, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, available at https://tools.ietf.org/html/rfc5280/.

[RFC 6960] IETF, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, available at https://tools.ietf.org/html/rfc6960/.

[BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), BCP 195, RFC 7525, May 2015, http://www.rfc-editor.org/info/bcp195.

[ICAM] National Security Systems and Identity, Credential and Access Management Sub-Committee Focus Group, Federal CIO Council, ICAM Lexicon, Version 0.5, March 2011.

[ISO/IEC 10646] International Standards Organization, Universal Coded Character Set, 2014, available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c063182_ISO_IEC_10646_2014.zip

[ISO/IEC 24745] International Standards Organization, Information technology – Security techniques – Biometric information protection, 2011, available at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946

[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site Scripting) Prevention Cheat Sheet, available at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[SAML] OASIS, SAML, Security Assertion Markup Language 2.0, v2.0, March 2005, available at http://oasis-open.org/standards#samlv2.0

[ISO 9241-11] International Organization for Standardization, Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on Usability, ISO 9241-11:1998, ISO: Geneva, Switzerland, 1998.

[UAX 15] [UAX 15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex 15, Version 9.0.0, February, 2016. Available at http://www.unicode.org/reports/tr15/

11.2. NIST Special Publications

NIST 800 Series Special Publications are available at: http://csrc.nist.gov/publications/nistpubs/index.html. The following publications may be of particular interest to those implementing systems of applications requiring e-authentication.

[SP 800-52] NIST Special Publication 800-52, Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, April, 2014.

[SP 800-53] NIST Special Publication 800-53, Revision 4, Recommended Security and Privacy Controls for Federal Information Systems and Organizations, August 2013 and Errata as of January 2015.

[SP 800-63C] NIST Special Publication 800-63C, Assertions and Federation. To be updated at publication

[SP 800-131A] NIST Special Publication 800-131A , Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, Revision 1, November 2015.

[SP 800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, December 2010.

11.3. Federal Information Processing Standards

FIPS can be found at: http://csrc.nist.gov/publications/fips/

[FIPS 140-2] Federal Information Processing Standard Publication 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.

[FIPS 198-1] Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008.

[FIPS 201] Federal Information Processing Standard Publication 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors, August 2013, available at http://dx.doi.org/10.6028/NIST.FIPS.201-2.

11.4. Legislation

[Privacy Act] Privacy Act of 1974 (P.L. 93-579), December 1974, available at http://www.justice.gov/opcl/privacy-act-1974

[E-Gov] E-Government Act [includes FISMA] (P.L. 107-347), December 2002, available at http://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

Appendix A: Strength of Memorized Secrets

This appendix is non-normative.

A.1 Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveals that the benefit of such rules is not nearly as significant as initially thought, although the impact on usability and memorability is severe.

Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy[ref]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.

It should be noted that there are many attacks associated with the use of passwords that are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.

A.2 Length

Password length has been found to be the primary factor in characterizing password strength. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by throttling the rate of login attempts permitted. In order to prevent an attacker (or a claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that throttling does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no throttling requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

A.3 Complexity

As noted above, composition rules are commonly used in an attempt to decrease the guessability of user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases the special characters that are not accepted might be an effort to avoid attacks like SQL Injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove spaces in typed passwords prior to verification.

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

A.5 Randomly-chosen secrets

Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LoA 2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long.

As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets.

A.6 Summary

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate throttling are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.