This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
NIST.SP.800-63B
NIST.SP.800-63B

Version management

Difference between version and

At line 1 added 71 lines
!!! Overview
[{$pagename}] is a [NIST Special Publication] titled “[Authentication] & [Lifecycle Management|Identity Lifecycle Management]” and focuses on [Best Practices Password]
[{$pagename}] is a publication from [National Institute of Standards and Technology]
[{$pagename}] changes the requirements for memorized secrets (ie [passwords]) in several ways.
* __[SHOULD]__ use [__long__|Password Strength], memorable [passwords]
* __[SHOULD] __Use of [Password Dictionary] of compromised passwords to disallow poor choices
* __[SHOULD NOT]__ use [Password Character Composition] Rules
* __[SHOULD NOT]__ [Identity questions] (name of first pet, etc.) as used in [Password Recovery]
* __[SHOULD NOT]__ arbitrary (e.g., periodic) [Password Periodic Change]
!! Session Bindings
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 [HTML]5 [Local Storage] due to the potential exposure of local storage to [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 Sections 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].
!! [NIST.SP.800-63B] and [Biometrics]
[NIST.SP.800-63B] has several hesitations on [Biometrics].
[NIST.SP.800-63B] 4.2.1. Permitted [Authenticator] Types ([Authenticator Assurance Level] 2) states:
Note: When [biometric] [authentication] implements the requirements in Section 5.2.3 the device has to be authenticated. Therefore, it is __unnecessary__ to implement another [Authentication Factor] with [biometrics] as the device is “something you have”, which serves as a valid [second factor|Multi-Factor Authentication] of the [authenticator].
[NIST.SP.800-63B] section 5.2.3. Use of [Biometrics] states:
\\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 [Revocation model] for [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). 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 have).
An authenticated protected channel between sensor (or endpoint containing a sensor that resists sensor replacement) and [verifier] [SHALL] be established and the sensor or endpoint authenticated prior to capturing the [biometric] sample from the claimant.
Empirical testing of the biometric system to be deployed SHALL demonstrate an EER of 1 in 1000 or better with respect to matching performance. The [biometric] system SHALL operate with an FMR of 1 in 1000 or better.
The biometric system [SHOULD] implement [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.
%%information
Note: [PAD] is being considered as a mandatory requirement in future editions of this guideline.
%%
The [biometric] system [SHALL] allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if PAD meeting the above requirements is implemented. Once that limit has been reached, the biometric [authenticator] SHALL either:
* Impose a delay of at least 30 seconds before the next attempt, increasing exponentially with each successive attempt, e.g., 1 minute before the following failed attempt, 2 minutes before the second following attempt, etc.
OR
* Disable the biometric user verification and offer another factor (a different biometric modality or a [PIN]/Passcode if it is not already a required factor) if such an alternative method is already implemented.
Determination of sensor/endpoint performance, integrity, and authenticity can be accomplished in several different ways, any of which are acceptable under this guideline. These include but are not limited to: authentication of the sensor or endpoint, certification by an approved accreditation authority, or runtime interrogation of signed metadata (e.g., attestation) as described in Section 5.2.4.
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 limited to one or more specific devices that are identified using approved cryptography.
* Biometric revocation, referred to as biometric template protection in [ISO/IEC 24745|ISO 24745], SHALL be implemented.
* 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 any training or research data has been derived.
[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|NIST.SP.800-63A].
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [SP 800-63B-working draft|https://github.com/usnistgov/800-63-3/tree/post-public-comment/sp800-63b|target='_blank'] - based on information obtained 2017-02-21-
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop