From NIST SP 800 63B, I understand that multi-factor OTP devices generate OTP for authentication after activation with additional authentication factors. For example, hardware devices installed on devices such as mobile phones. In addition to activation information, a multi-factor OTP authenticator contains two persistent values, a symmetric key and a nonce that persist for the life of the device.
It is important to note that if the claimant’s authentication is denied due to repeated use of OTP, the validator may warn the claimant in case the attacker is able to authenticate in advance.
Because biometrics is probabilistic rather than deterministic, it should only be used in conjuction with other methods of authentication. You should also limit the number of attempts before lockout to 5. Anothet issue is that biometric data is not a secret. Their face can be found online and their fingerprints can be lifted from items they touch. High resolution images can capture their iris data. There is also special regulation surrounding biometrics so all biometric data should only be transmitted over the authenticated protected channel.
Great point. Biometric authentication is often seen as the future of going passwordless, but there are many problems surrounding it as you mentioned. Yes, it may be more difficult to get individuals’ face scans or iris scans, but vulnerabilities still exist and so implementing MFA should still be considered.
The purpose of this document seems to revolve around the recommendations on the types of authentication processes. The authentication process includes the type of authentication based on the assurance level and the recommendations on the lifecycle. Assurance level 2 states the permitted authenticator types including those that qualify for multi-factor such as OTP, cryptographic software, and cryptographic device.
This reading is pivoting on authentication and lifecycle manage Multifactor authentication gets its name from the use of multiple authentication factors. So, what is a factor? You can think of a factor as a category of authentication. There are three authentication factors that can be used: something you know, something you have, and something you are. Something you know would be a password, a birthday or some other personal information. Something you have would be a one-time use token, a smart card or some other artifact that you might have in your physical possession. Something you are would be your biometric identity, like a fingerprint or a speech pattern. .Authentication binding is establishing an association between a specific authenticator, like Active Directory and the subscriber account to enable use of the authenticator.
I appreciate your post because you gave a good description of authentication and multi-factor authentication from a birds-eye view. It incorporated all the factors of authentication, their definitions, and how these factors can come together in MFA to make systems more secured in a way that is easy to understand.
AAL defines the requirements for authentication. For online services that someone needs to access repeatedly, authentication is used to ensure that they are the same person who previously verified their identity on that account. People must prove that they can control the authenticator once bound to the report to authenticate. Passwords are typical examples of authenticators.
AAL1: Allows single-factor or multi-factor authentication with little to no restrictions on the type of authenticator accepted.
AAL2: authentication shall occur using either a multi-factor authenticator or a combination of two single-factor authenticators.
AAL3: Only multiple authentications, with strict authentication types restrictions, are allowed. Two authenticator categories must be represented: something you know, have, and something you are. The “something you have” authenticator must be a hardware key, and the “something you are” authenticator must be anti-forgery.
A key takeaway from NIST SP 800-63B is that even AAL2 requires the use of MFA and cryptographic techniques. I think this is important to note because only the lowest level security categorization systems should not require MFA or some type of cryptographic assurance at login, but I feel like I have used many different services that could have an overall security categorization as moderate that do not require anything more than a password (for example, banking apps). Plus, if banking information such as microtransactions are commonly used in identity resolution, and the software used to access banking information is not very secure, this lack of authentication protocol puts higher forms of authentication in jeopardy.
I agree with you that AAL2 needs to use MFA and encryption as well. The lowest level of security classification system requires MFA or some type of encryption assurance at login and can prevent risks from occurring from a lower level. On the other hand, software used to access banking information is not secure and lack of authentication can put vulnerabilities at risk.
With each level of authentication assurance, organizations need to increase the strength of their authentication process based on information stored. AAL1 requires either single-factor or multi-factor authentication technology as outlined in this document. AAL2 and multi-factor authentication is needed, at a minimum, whenever PII is made available online. AAL3 requires multi-factor authentication including a hardware-based authenticator and an authenticator that provides verifier impersonation resistance (could be the same device).
HI Patrick, great point about PII requiring MFA according to this reading. With the increased climate for cybersecurity attacks, it is critical that all institutions handling this form of data uses MFA at the very least.
NIST Digital Identity Guidelines 800-63B provides a more prescribed approach to the AAL process and each level’s respective requirements. For example, 800-63B outlines a permitted authenticator type, reauthentication, security controls, and record retention policy required by each particular AAL process. Required security controls can be found in NIST SP 800-53 by assigning controls based on low, moderate, or high baselines and their subsequent resistance requirements (NIST 800-63A), furthering our understanding of how these documents support one another.
NIST 800-63B includes the recommendations for the authentication process. There are three levels of Authenticator Assurance Levels (AALs) are mentioned within the NIST 800-63B. The recommendation also provides a life cycle of the authenticators including the revocation process. Authenticator Assurance Level 1 requires using the single-factor or multi-factor authentication. Authenticator Assurance Level 2 requires using a multi-factor authentication using a secure authentication protocol. Authenticator Assurance Level 3 requires authenticator to have a hardware-based authenticator to prove the identity.
NIST SP 800-63B is concerned with the implementation of different digital authentication types. It is interesting to observe the different requirements stated in this document depending on different Authentication Assurance Levels, or AALs. Some of the different required security controls include MitM resistance, Replay Resistance, and Records Retention Policies. The document also provides different requirements for types of Authenticators, which include memorized secrets, look-up secrets, and out-of-band authenticators and verifiers.
There are multiple events that occur in the lifecycle of an Authenticator. These events include binding, loss, theft, unauthorized duplication, expiration and revocation.
Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication. If and when an authenticator expires, it SHALL NOT be usable for authentication. Revocation referred to as termination. refers to removal of the binding between an authenticator. The subscriber no longer meets its eligibility requirements which causes the surrender or certify destruction of any physical authenticator containing certified attributes signed by the CSP as soon as practical after revocation or termination takes place
I found the authenticator lifecycle management to be the most interesting. The article mentions, authenticator lifecycle management is “a number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. These events binding, loss, theft, unauthorized duplication, expiration, and revocation.” Authenticator binding reverts o being associated with a specific authenticator and a subscriber’s account, enabling the authenticator to be used.
Loss, Theft, Damage, and unauthorized duplication can compromise authenticators. Suspension, revocation, or destruction of compromised authenticators should occur promptly as practical following detection. Agencies should establish time limits for this process. However, when an authenticator is attempted to 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.
One takeaway from this reading are the different forms of authentication-based attacks, and how to mitigate the effects from said attacks. Some examples include theft (when an attacker steals a physical authenticator/cryptographic piece of hardware). The suggested mitigation measures included implementing 2FA/MFA (so one stolen piece of hardware would be rendered useless alone)–especially adding in biometrics (it is much easier to steal a piece of hardware than someone’s fingerprint, for example). Another listed threat is phishing/pharming, which involves social engineering and trickery to infiltrate a system. The NIST-suggested mitigation measure is to avoid authenticators that would fall victim to social engineering (i.e. customer service agents) and implementing authenticators that demonstrate impersonator-resistance.
NIST SP 800-63B focuses on how an individual can securely authenticate to a CSP to access a digital service or set of past digital services. For assistance in which several visits are applicable, a successful authentication provides the reasonable risk-based assurance that the subscriber accessing the service at that instance is the same as who initially accessed the service. An AAL categorization describes the robustness of this confidence.
The underlisted three AALs define the subsets of options agencies can select from based on their risk profile:
AAL1 assures that the claimant controls an authenticator bound to the subscriber’s account and requires either single-factor or multi-factor authentication using available authentication technologies.
AAL2 confidence that the claimant’s control authenticator(s) is bound to the subscriber’s account.
AAL3 provides very high assurance that the claimant’s control authenticator(s) is bound to the subscriber’s account is based on proof of possession of a key through a cryptographic protocol.
From NIST SP 800 63B, I understand that multi-factor OTP devices generate OTP for authentication after activation with additional authentication factors. For example, hardware devices installed on devices such as mobile phones. In addition to activation information, a multi-factor OTP authenticator contains two persistent values, a symmetric key and a nonce that persist for the life of the device.
It is important to note that if the claimant’s authentication is denied due to repeated use of OTP, the validator may warn the claimant in case the attacker is able to authenticate in advance.
Because biometrics is probabilistic rather than deterministic, it should only be used in conjuction with other methods of authentication. You should also limit the number of attempts before lockout to 5. Anothet issue is that biometric data is not a secret. Their face can be found online and their fingerprints can be lifted from items they touch. High resolution images can capture their iris data. There is also special regulation surrounding biometrics so all biometric data should only be transmitted over the authenticated protected channel.
Hi Madalyn,
Great point. Biometric authentication is often seen as the future of going passwordless, but there are many problems surrounding it as you mentioned. Yes, it may be more difficult to get individuals’ face scans or iris scans, but vulnerabilities still exist and so implementing MFA should still be considered.
The purpose of this document seems to revolve around the recommendations on the types of authentication processes. The authentication process includes the type of authentication based on the assurance level and the recommendations on the lifecycle. Assurance level 2 states the permitted authenticator types including those that qualify for multi-factor such as OTP, cryptographic software, and cryptographic device.
This reading is pivoting on authentication and lifecycle manage Multifactor authentication gets its name from the use of multiple authentication factors. So, what is a factor? You can think of a factor as a category of authentication. There are three authentication factors that can be used: something you know, something you have, and something you are. Something you know would be a password, a birthday or some other personal information. Something you have would be a one-time use token, a smart card or some other artifact that you might have in your physical possession. Something you are would be your biometric identity, like a fingerprint or a speech pattern. .Authentication binding is establishing an association between a specific authenticator, like Active Directory and the subscriber account to enable use of the authenticator.
Kofi,
I appreciate your post because you gave a good description of authentication and multi-factor authentication from a birds-eye view. It incorporated all the factors of authentication, their definitions, and how these factors can come together in MFA to make systems more secured in a way that is easy to understand.
-Mike
AAL defines the requirements for authentication. For online services that someone needs to access repeatedly, authentication is used to ensure that they are the same person who previously verified their identity on that account. People must prove that they can control the authenticator once bound to the report to authenticate. Passwords are typical examples of authenticators.
AAL1: Allows single-factor or multi-factor authentication with little to no restrictions on the type of authenticator accepted.
AAL2: authentication shall occur using either a multi-factor authenticator or a combination of two single-factor authenticators.
AAL3: Only multiple authentications, with strict authentication types restrictions, are allowed. Two authenticator categories must be represented: something you know, have, and something you are. The “something you have” authenticator must be a hardware key, and the “something you are” authenticator must be anti-forgery.
A key takeaway from NIST SP 800-63B is that even AAL2 requires the use of MFA and cryptographic techniques. I think this is important to note because only the lowest level security categorization systems should not require MFA or some type of cryptographic assurance at login, but I feel like I have used many different services that could have an overall security categorization as moderate that do not require anything more than a password (for example, banking apps). Plus, if banking information such as microtransactions are commonly used in identity resolution, and the software used to access banking information is not very secure, this lack of authentication protocol puts higher forms of authentication in jeopardy.
Hi Michael,
I agree with you that AAL2 needs to use MFA and encryption as well. The lowest level of security classification system requires MFA or some type of encryption assurance at login and can prevent risks from occurring from a lower level. On the other hand, software used to access banking information is not secure and lack of authentication can put vulnerabilities at risk.
With each level of authentication assurance, organizations need to increase the strength of their authentication process based on information stored. AAL1 requires either single-factor or multi-factor authentication technology as outlined in this document. AAL2 and multi-factor authentication is needed, at a minimum, whenever PII is made available online. AAL3 requires multi-factor authentication including a hardware-based authenticator and an authenticator that provides verifier impersonation resistance (could be the same device).
HI Patrick, great point about PII requiring MFA according to this reading. With the increased climate for cybersecurity attacks, it is critical that all institutions handling this form of data uses MFA at the very least.
NIST Digital Identity Guidelines 800-63B provides a more prescribed approach to the AAL process and each level’s respective requirements. For example, 800-63B outlines a permitted authenticator type, reauthentication, security controls, and record retention policy required by each particular AAL process. Required security controls can be found in NIST SP 800-53 by assigning controls based on low, moderate, or high baselines and their subsequent resistance requirements (NIST 800-63A), furthering our understanding of how these documents support one another.
NIST 800-63B includes the recommendations for the authentication process. There are three levels of Authenticator Assurance Levels (AALs) are mentioned within the NIST 800-63B. The recommendation also provides a life cycle of the authenticators including the revocation process. Authenticator Assurance Level 1 requires using the single-factor or multi-factor authentication. Authenticator Assurance Level 2 requires using a multi-factor authentication using a secure authentication protocol. Authenticator Assurance Level 3 requires authenticator to have a hardware-based authenticator to prove the identity.
NIST SP 800-63B is concerned with the implementation of different digital authentication types. It is interesting to observe the different requirements stated in this document depending on different Authentication Assurance Levels, or AALs. Some of the different required security controls include MitM resistance, Replay Resistance, and Records Retention Policies. The document also provides different requirements for types of Authenticators, which include memorized secrets, look-up secrets, and out-of-band authenticators and verifiers.
There are multiple events that occur in the lifecycle of an Authenticator. These events include binding, loss, theft, unauthorized duplication, expiration and revocation.
Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication. If and when an authenticator expires, it SHALL NOT be usable for authentication. Revocation referred to as termination. refers to removal of the binding between an authenticator. The subscriber no longer meets its eligibility requirements which causes the surrender or certify destruction of any physical authenticator containing certified attributes signed by the CSP as soon as practical after revocation or termination takes place
I found the authenticator lifecycle management to be the most interesting. The article mentions, authenticator lifecycle management is “a number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. These events binding, loss, theft, unauthorized duplication, expiration, and revocation.” Authenticator binding reverts o being associated with a specific authenticator and a subscriber’s account, enabling the authenticator to be used.
Loss, Theft, Damage, and unauthorized duplication can compromise authenticators. Suspension, revocation, or destruction of compromised authenticators should occur promptly as practical following detection. Agencies should establish time limits for this process. However, when an authenticator is attempted to 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.
One takeaway from this reading are the different forms of authentication-based attacks, and how to mitigate the effects from said attacks. Some examples include theft (when an attacker steals a physical authenticator/cryptographic piece of hardware). The suggested mitigation measures included implementing 2FA/MFA (so one stolen piece of hardware would be rendered useless alone)–especially adding in biometrics (it is much easier to steal a piece of hardware than someone’s fingerprint, for example). Another listed threat is phishing/pharming, which involves social engineering and trickery to infiltrate a system. The NIST-suggested mitigation measure is to avoid authenticators that would fall victim to social engineering (i.e. customer service agents) and implementing authenticators that demonstrate impersonator-resistance.
NIST SP 800-63B focuses on how an individual can securely authenticate to a CSP to access a digital service or set of past digital services. For assistance in which several visits are applicable, a successful authentication provides the reasonable risk-based assurance that the subscriber accessing the service at that instance is the same as who initially accessed the service. An AAL categorization describes the robustness of this confidence.
The underlisted three AALs define the subsets of options agencies can select from based on their risk profile:
AAL1 assures that the claimant controls an authenticator bound to the subscriber’s account and requires either single-factor or multi-factor authentication using available authentication technologies.
AAL2 confidence that the claimant’s control authenticator(s) is bound to the subscriber’s account.
AAL3 provides very high assurance that the claimant’s control authenticator(s) is bound to the subscriber’s account is based on proof of possession of a key through a cryptographic protocol.