This guideline has detailed information on the different types of authentication processes such as an Authentic Assurance Level (ALL). Each level has a certain amount of trust in control and possession of the authentication. AAL has 3 stages AAL (some assurance), AAL2 (high confidence), and AAL3 (very high confidence). Here AAL3 provides the most security for protecting highly sensitive information with multifactor authentication methods.
Authentication method faces various threats such as phishing attacks, social engineering attacks, XSS and other side-channel attacks, etc. Generally, the attacker targets government services, and government information systems, this guideline helps in understanding the risk factor and helps to implement the mitigation techniques. Authentication and life cycle management is the process of how the authenticated confirm the identity of the user based on single-use authentication, multi-factor authentication, and more. The authorized user can identify, authenticate a legitimate user. It’s mandatory to complete authentication life cycle management in an authorized way. If it’s not completed in the proper way there is a result of loss of trust, data theft, unauthorized access, and more. This document defines how each step to authentication and lifecycle management takes place.
NIST SP 800 63B provides recommendations on the type of authentication process, including the selection of authenticators, that can be used for various authenticator assurance levels. 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 has previously verified their identity on the account. To authenticate, people must prove that they can control the authenticator that was previously tied to the account. A password is a common example of an authenticator.
AAL1: Allows single-factor authentication, with almost no restrictions on accepted authenticator types.
AAL2: Allows only multi-factor authentication, where a combination of two types of authenticators must be used.
AAL3: Only multi-factor authentication is allowed, with strict restrictions on the allowed authenticator types. Of the three authenticator categories: What You Know, What You Have, and What You Are, two of which must be represented.
NIST SP 800 – 63B provide technical guidelines about authentication and the lifecycle management to agencies for the implementation of digital authentication from the design phase to the implementation phase. It detailed the Authenticator Assurance Levels. It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft. It also detailed the strength of an authentication transaction characterized by an ordinal measurement known as AAL. The Stronger authentication (used in a higher AAL) requires malicious actors to have better capabilities and expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks.
Authenticator Assurance Level 1 (AAL1) provides some assurance on either single-factor or multi-factor authentication technology for the claimant controls to the subscriber’s account. The successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
Authenticator Assurance Level 2 (AAL2) provides high confidence proof of possession and control of two different authentication factors for the claimant control required through secure authentication protocol(s) and cryptographic techniques are required.
Authenticator Assurance Level 3 (AAL3) provides very high confidence authentication based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance and the same device may fulfill both these requirements for claimants to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
It was interesting to learn about authenticator threats and mitigations as it is essential to understand given the nature of data shared with many government information systems. Common threats include but are not limited to: phishing, assertion manufacture or modification, theft, social engineering, duplication, eavesdropping, and side-channel attacks. Furthermore, some mitigations mentioned were endpoint security, multi-factor authentication, using authenticators that offer verifier impersonation resistance, avoiding the use of authenticators that present risk of social engineering, etc. Said mitigation strategies can be effective in reducing the risk of an attacker compromising the authenticator and masquerading as the authenticator’s owner.
NIST SP 800 63B speaks about authenticator assurance levels, verification requirements and lifecycle management. The key points of this guide I like learning about were the single factor OTP, authenticators, and MF OTP. This section speaks about a single factor OTP device, which is something you have. These devices are similar to look up secret authenticators. OTP authenticators contain 2 persistent values, a symmetric key and a nonce that is changed each time the authenticator is used. MF OTP devices generate OTP for use in authentication after activation through an additional authentication factor, Hardware and software that has been installed on mobile phones. MF OTP authentication memorizes secret biometric to obtain the OTP from the authenticator. Each use shall require the input of another factor. MFA has always been a solid way of preventing unauthorized access of your personal data and information.
An interesting takeaway from this reading is different types of authenticators and their processes. Digital authentication is the process of determining the validity of one or more authenticators used to claim the digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. The publication also outlines the life cycle of identity management and goes in depth about different levels of authenticators.
NIST SP 800 63B details how an individual can authenticate to a credential service provider to access a digital service. I found the section on authenticator requirements interesting. In particular, section 5.2.2 (page 25) which deals with rate limiting.
Implementing rate limiting prevents faster than human authentication attempts that try to guess authentication factors. For example, after a failed authentication attempt, the system may require a CAPTCHA to be completed before another attempt is allowed. This prevents bots from trying to brute force authentication. Rate limiting provides an additional defensive layer that works in conjunction with MFA, password complexity requirements, and other controls. This helps to establish defense in depth.
I enjoyed the information presented in the section for session management. The recommendations for what should and should not be considered when creating secrets for session binding was interesting. My biggest takeaway from reading the section is that the use of non-persistent session secrets is extremely important. It is mentioned several times that the secrets must time out and that users have to re-authenticate. This can be seen in everyday use of the internet while using a website that you log into. After a certain period of time the website will log you out and require you to re-authenticate. There is no stated recommendation in this section for the timeout period. This would make sense to wide range of the sensitivities of the system the session is for. There is no one-size-fits-all for session time outs.
Hi Ryan,
What’s interesting is that authentication is just a way of doing things on the internet, it’s just to verify that the purported person’s identity is real, but that doesn’t explain who the purported person is in real life.
I found the information on Authenticator Recovery to be something I thought about in the past. It’s nice when you have security through an authenticator for a bank account – but a problem occurs when the backup method just requires you to answer 2 security questions in order to reset your authenticator. For example, if I was a friend of someone and I wanted to transfer money out of their checking account into mine – I could easily guess the city they were born from and their first pet if I know them well enough. That is provided that I have the information afterwards such as the reset link that will be sent to their email; however again you can simply repeat these steps until you have access to all of their information. The example they use to combat this is that it should not be possible to leverage one authenticator to obtain another authenticator of a different factor.
Something I took away from NIST SP 800 63B was the reduced significance of “complex” passwords. I found this particular part interesting because ten-fifteen years ago I could make my password whatever I wanted, but now most websites will set requirements such as composition rules(one digit, one symbol, etc.), a specific password length, and password reset timelines. Regardless of this increased annoyance & level of complexity, these rules aren’t that important when it comes to attacks such as keystroke logging, phishing, & social engineering. The most secure password, realistically, is one that the user themselves don’t even know & can be set up through a password manager like Last Pass or Kaspersky.
I can’t agree more with this. Mainly because most end-users (including cybersecurity professionals) at some point write down their passwords or improperly manage them. Even I have been careless with a few more minor accounts. The problem with this though is when passwords are exposed that they are retained within a database and can be used to target more than one of your accounts. Which is why the end-solution is to convert into a passwordless system where the end user can provide something like PKI via access cards. I just don’t know how to implement something like this commercially, since most consumers don’t want to have additional things they need to carry. And the use of public computers would be more difficult since that data could be potentially stolen when using a smart card reader (I would have to do more research here.).
NIST 800 63B is a document to provide requirements for authenticator assurance levels and the lifecycle management to agencies for the implementation of digital authentication. In fact, the document provides details of three authenticator assurance levels, recommendations of life cycle of authenticators including revocation in the loss/theft situations. The document also provides common threats and mitigations of these threats. The Appendix A gives us how to create passwords better to protect data based on length and complexity of password to gain the strength of password.
I found section 5.2.8 very interesting, Replay Resistance
Replay Attack- A replay attack is a category of network attack in which an attacker detects a data transmission and fraudulently has it delayed or repeated. The delay or repeat of the data transmission is carried out by the sender or by the malicious entity, who intercepts the data and retransmits it.
An authentication process resists replay attacks if it is impractical to achieve a successful
authentication by recording and replaying a previous authentication message. Replay resistance
is in addition to the replay-resistant nature of authenticated protected channel protocols, since the
output could be stolen prior to entry into the protected channel. Protocols that use nonces or
challenges to prove the “freshness” of the transaction are resistant to replay attacks since the
verifier will easily detect when old protocol messages are replayed since they will not contain the
appropriate nonces or timeliness data.
Examples of replay-resistant authenticators are OTP devices, cryptographic authenticators, and
look-up secrets.
In contrast, memorized secrets are not considered replay resistant because the authenticator
output — the secret itself — is provided for each authentication
This part in the article stood out to me and I really want to learn more about it. This document “provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs). Three authenticators requirements were mentioned in this document such as Authenticator Assurance Level 1- provides some assurance that the claimant controls an authenticator bound to the subscriber’s account.
Authenticator Assurance Level 2- provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account.
Authenticator Assurance Level 3- provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account
Overall, I think this reading did a nice job defining technical requirements for each of the three authenticator assurance levels. Similar to SP 800-63A, I found the threat considerations very interesting. Particularly unauthorized binding threats/attacks, which is when an attacker is able to cause an authenticator under their control to be bound to a subscriber’s account, was a concept I was not previously aware of.
I found section 8.1 on authenticator threats to be interesting. This section reviews the different types of authenticators (something you know, something you have, something you are) and then dives into specific threats that different identifiers face. For example, “something you have” could be stolen or duplicated. “Something you know” could be vulnerable to social engineering or guessing. Next, this section reviewed the mitigation for each of the threats listed. For example, multi-factor authentication or a combination of authenticators could be used to combat the theft of an authenticator. Using an authenticator that freezes after a specified number of repeated failed activation attempts can be used to combat guessing of “something you know” authenticators.
NIST publication explains different authenticator assurance levels and their permitted authenticator types. The document recommends choices of authenticators based on the assurance levels and authentication processes.
– AAL1: provides some assurance that requires single or multifactor authentication
-AAL2: provides high confidence that asks for proof of possession and control of two different authentication factors.
-ALL3: provides very high confidence and requires a cryptographic protocol with a hardware-based authenticator.
The personally most interesting part for me was the section on the session management. The browser cookies created and used by tracking subscriber access to the server should be tagged as inaccessible via javascript and expire at or soon after the session’s validity period. Now I started to consider if the web browser cookies or other application cookies need to be compliant with the same requirement as we all know some of them to track us after our session is expired.
The reoccurring topics of this reading are authentication and its various types / methods. This document provides insight, guidelines, research, and outreach efforts “in information system security, and its collaborative activities with industry, government, and academic organizations.” Moreover, this document also “defines technical requirements for each of the three authenticator assurance levels.”
I found the sections on reauthentication to be of most interest. Section 4.1.3 on reauthentication mentions that at At AAL1 there is a need to make a subscriber reauthenticate themselves every 30 days regardless of user activity. On the other hand, we see section 4.2.3 mention that at AAL2 there is a need for a subscriber to reauthenticate themselves every 12 hours, regardless of user activity, it also states that the subscriber should have to reauthenticate themselves after 30 minutes of inactivity. “At AAL3, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity”, and at least every 15 minutes of inactivity.
Mohammed Syed says
This guideline has detailed information on the different types of authentication processes such as an Authentic Assurance Level (ALL). Each level has a certain amount of trust in control and possession of the authentication. AAL has 3 stages AAL (some assurance), AAL2 (high confidence), and AAL3 (very high confidence). Here AAL3 provides the most security for protecting highly sensitive information with multifactor authentication methods.
Authentication method faces various threats such as phishing attacks, social engineering attacks, XSS and other side-channel attacks, etc. Generally, the attacker targets government services, and government information systems, this guideline helps in understanding the risk factor and helps to implement the mitigation techniques. Authentication and life cycle management is the process of how the authenticated confirm the identity of the user based on single-use authentication, multi-factor authentication, and more. The authorized user can identify, authenticate a legitimate user. It’s mandatory to complete authentication life cycle management in an authorized way. If it’s not completed in the proper way there is a result of loss of trust, data theft, unauthorized access, and more. This document defines how each step to authentication and lifecycle management takes place.
Yangyuan Lin says
NIST SP 800 63B provides recommendations on the type of authentication process, including the selection of authenticators, that can be used for various authenticator assurance levels. 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 has previously verified their identity on the account. To authenticate, people must prove that they can control the authenticator that was previously tied to the account. A password is a common example of an authenticator.
AAL1: Allows single-factor authentication, with almost no restrictions on accepted authenticator types.
AAL2: Allows only multi-factor authentication, where a combination of two types of authenticators must be used.
AAL3: Only multi-factor authentication is allowed, with strict restrictions on the allowed authenticator types. Of the three authenticator categories: What You Know, What You Have, and What You Are, two of which must be represented.
Oluwaseun Soyomokun says
NIST SP 800 – 63B provide technical guidelines about authentication and the lifecycle management to agencies for the implementation of digital authentication from the design phase to the implementation phase. It detailed the Authenticator Assurance Levels. It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft. It also detailed the strength of an authentication transaction characterized by an ordinal measurement known as AAL. The Stronger authentication (used in a higher AAL) requires malicious actors to have better capabilities and expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks.
Authenticator Assurance Level 1 (AAL1) provides some assurance on either single-factor or multi-factor authentication technology for the claimant controls to the subscriber’s account. The successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
Authenticator Assurance Level 2 (AAL2) provides high confidence proof of possession and control of two different authentication factors for the claimant control required through secure authentication protocol(s) and cryptographic techniques are required.
Authenticator Assurance Level 3 (AAL3) provides very high confidence authentication based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance and the same device may fulfill both these requirements for claimants to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
Elizabeth Gutierrez says
It was interesting to learn about authenticator threats and mitigations as it is essential to understand given the nature of data shared with many government information systems. Common threats include but are not limited to: phishing, assertion manufacture or modification, theft, social engineering, duplication, eavesdropping, and side-channel attacks. Furthermore, some mitigations mentioned were endpoint security, multi-factor authentication, using authenticators that offer verifier impersonation resistance, avoiding the use of authenticators that present risk of social engineering, etc. Said mitigation strategies can be effective in reducing the risk of an attacker compromising the authenticator and masquerading as the authenticator’s owner.
Corey Arana says
NIST SP 800 63B speaks about authenticator assurance levels, verification requirements and lifecycle management. The key points of this guide I like learning about were the single factor OTP, authenticators, and MF OTP. This section speaks about a single factor OTP device, which is something you have. These devices are similar to look up secret authenticators. OTP authenticators contain 2 persistent values, a symmetric key and a nonce that is changed each time the authenticator is used. MF OTP devices generate OTP for use in authentication after activation through an additional authentication factor, Hardware and software that has been installed on mobile phones. MF OTP authentication memorizes secret biometric to obtain the OTP from the authenticator. Each use shall require the input of another factor. MFA has always been a solid way of preventing unauthorized access of your personal data and information.
Shubham Patil says
An interesting takeaway from this reading is different types of authenticators and their processes. Digital authentication is the process of determining the validity of one or more authenticators used to claim the digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. The publication also outlines the life cycle of identity management and goes in depth about different levels of authenticators.
Matthew Bryan says
NIST SP 800 63B details how an individual can authenticate to a credential service provider to access a digital service. I found the section on authenticator requirements interesting. In particular, section 5.2.2 (page 25) which deals with rate limiting.
Implementing rate limiting prevents faster than human authentication attempts that try to guess authentication factors. For example, after a failed authentication attempt, the system may require a CAPTCHA to be completed before another attempt is allowed. This prevents bots from trying to brute force authentication. Rate limiting provides an additional defensive layer that works in conjunction with MFA, password complexity requirements, and other controls. This helps to establish defense in depth.
Ryan Trapp says
I enjoyed the information presented in the section for session management. The recommendations for what should and should not be considered when creating secrets for session binding was interesting. My biggest takeaway from reading the section is that the use of non-persistent session secrets is extremely important. It is mentioned several times that the secrets must time out and that users have to re-authenticate. This can be seen in everyday use of the internet while using a website that you log into. After a certain period of time the website will log you out and require you to re-authenticate. There is no stated recommendation in this section for the timeout period. This would make sense to wide range of the sensitivities of the system the session is for. There is no one-size-fits-all for session time outs.
Yangyuan Lin says
Hi Ryan,
What’s interesting is that authentication is just a way of doing things on the internet, it’s just to verify that the purported person’s identity is real, but that doesn’t explain who the purported person is in real life.
Michael Duffy says
I found the information on Authenticator Recovery to be something I thought about in the past. It’s nice when you have security through an authenticator for a bank account – but a problem occurs when the backup method just requires you to answer 2 security questions in order to reset your authenticator. For example, if I was a friend of someone and I wanted to transfer money out of their checking account into mine – I could easily guess the city they were born from and their first pet if I know them well enough. That is provided that I have the information afterwards such as the reset link that will be sent to their email; however again you can simply repeat these steps until you have access to all of their information. The example they use to combat this is that it should not be possible to leverage one authenticator to obtain another authenticator of a different factor.
Alexander William Knoll says
Something I took away from NIST SP 800 63B was the reduced significance of “complex” passwords. I found this particular part interesting because ten-fifteen years ago I could make my password whatever I wanted, but now most websites will set requirements such as composition rules(one digit, one symbol, etc.), a specific password length, and password reset timelines. Regardless of this increased annoyance & level of complexity, these rules aren’t that important when it comes to attacks such as keystroke logging, phishing, & social engineering. The most secure password, realistically, is one that the user themselves don’t even know & can be set up through a password manager like Last Pass or Kaspersky.
Michael Duffy says
I can’t agree more with this. Mainly because most end-users (including cybersecurity professionals) at some point write down their passwords or improperly manage them. Even I have been careless with a few more minor accounts. The problem with this though is when passwords are exposed that they are retained within a database and can be used to target more than one of your accounts. Which is why the end-solution is to convert into a passwordless system where the end user can provide something like PKI via access cards. I just don’t know how to implement something like this commercially, since most consumers don’t want to have additional things they need to carry. And the use of public computers would be more difficult since that data could be potentially stolen when using a smart card reader (I would have to do more research here.).
Hang Nu Song Nguyen says
NIST 800 63B is a document to provide requirements for authenticator assurance levels and the lifecycle management to agencies for the implementation of digital authentication. In fact, the document provides details of three authenticator assurance levels, recommendations of life cycle of authenticators including revocation in the loss/theft situations. The document also provides common threats and mitigations of these threats. The Appendix A gives us how to create passwords better to protect data based on length and complexity of password to gain the strength of password.
Jason Burwell says
I found section 5.2.8 very interesting, Replay Resistance
Replay Attack- A replay attack is a category of network attack in which an attacker detects a data transmission and fraudulently has it delayed or repeated. The delay or repeat of the data transmission is carried out by the sender or by the malicious entity, who intercepts the data and retransmits it.
An authentication process resists replay attacks if it is impractical to achieve a successful
authentication by recording and replaying a previous authentication message. Replay resistance
is in addition to the replay-resistant nature of authenticated protected channel protocols, since the
output could be stolen prior to entry into the protected channel. Protocols that use nonces or
challenges to prove the “freshness” of the transaction are resistant to replay attacks since the
verifier will easily detect when old protocol messages are replayed since they will not contain the
appropriate nonces or timeliness data.
Examples of replay-resistant authenticators are OTP devices, cryptographic authenticators, and
look-up secrets.
In contrast, memorized secrets are not considered replay resistant because the authenticator
output — the secret itself — is provided for each authentication
Ornella Rhyne says
This part in the article stood out to me and I really want to learn more about it. This document “provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs). Three authenticators requirements were mentioned in this document such as Authenticator Assurance Level 1- provides some assurance that the claimant controls an authenticator bound to the subscriber’s account.
Authenticator Assurance Level 2- provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account.
Authenticator Assurance Level 3- provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account
Bryan Garrahan says
Overall, I think this reading did a nice job defining technical requirements for each of the three authenticator assurance levels. Similar to SP 800-63A, I found the threat considerations very interesting. Particularly unauthorized binding threats/attacks, which is when an attacker is able to cause an authenticator under their control to be bound to a subscriber’s account, was a concept I was not previously aware of.
Amelia Safirstein says
I found section 8.1 on authenticator threats to be interesting. This section reviews the different types of authenticators (something you know, something you have, something you are) and then dives into specific threats that different identifiers face. For example, “something you have” could be stolen or duplicated. “Something you know” could be vulnerable to social engineering or guessing. Next, this section reviewed the mitigation for each of the threats listed. For example, multi-factor authentication or a combination of authenticators could be used to combat the theft of an authenticator. Using an authenticator that freezes after a specified number of repeated failed activation attempts can be used to combat guessing of “something you know” authenticators.
Miray Bolukbasi says
NIST publication explains different authenticator assurance levels and their permitted authenticator types. The document recommends choices of authenticators based on the assurance levels and authentication processes.
– AAL1: provides some assurance that requires single or multifactor authentication
-AAL2: provides high confidence that asks for proof of possession and control of two different authentication factors.
-ALL3: provides very high confidence and requires a cryptographic protocol with a hardware-based authenticator.
The personally most interesting part for me was the section on the session management. The browser cookies created and used by tracking subscriber access to the server should be tagged as inaccessible via javascript and expire at or soon after the session’s validity period. Now I started to consider if the web browser cookies or other application cookies need to be compliant with the same requirement as we all know some of them to track us after our session is expired.
Joshua Moses says
The reoccurring topics of this reading are authentication and its various types / methods. This document provides insight, guidelines, research, and outreach efforts “in information system security, and its collaborative activities with industry, government, and academic organizations.” Moreover, this document also “defines technical requirements for each of the three authenticator assurance levels.”
I found the sections on reauthentication to be of most interest. Section 4.1.3 on reauthentication mentions that at At AAL1 there is a need to make a subscriber reauthenticate themselves every 30 days regardless of user activity. On the other hand, we see section 4.2.3 mention that at AAL2 there is a need for a subscriber to reauthenticate themselves every 12 hours, regardless of user activity, it also states that the subscriber should have to reauthenticate themselves after 30 minutes of inactivity. “At AAL3, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity”, and at least every 15 minutes of inactivity.