Implementing the Authentication Assurance Standard
This guidance provides additional information and examples to aid with the understanding of and compliance with the controls in the Authentication Assurance standard.
Help us create the best guidance possible
If you would like anything added to or clarified in this guidance, email the Identification Management team email@example.com.
Authentication Assurance covers the implementation of various mechanisms used to recognise an Entity when they return to a context, referred to as Authenticators. The Authenticator is registered to a specific instance of Entity Information often termed an account. General information on the types and forms of these Authenticators can be found in the guidance on Authenticator types.
Entities that can act in a system can be both person and non-person (machine) entities. This guidance is primarily informed by threats and controls for person entities. While person entities can utilise all 3 factor types, machine entities generally use only 2 – possession and biometric (often referred to as inherence). A machine cannot be independently challenged for a knowledge factor.
When the Entity is a machine, then ‘something it is’ needs to be a characteristic of the hardware — such as a unique code burnt into a component at manufacture and not subsequently able to be changed. A machine can also possess something which is securely stored in software such as a certificate. Currently, a machine cannot possess something it knows without sharing this knowledge with a programmer.
Authentication assurance controls are designed to reduce the likelihood of the following outcomes:
- someone else has locally acquired use of the Authenticator
- someone else has gained remote possession of the Authenticator
- someone else uses the Authenticator with the collaboration and assistance of the authorised person.
Definitions for key terms used in this guidance can be found in Identification terminology.
This is living guidance and will be evolved and expanded over time to meet the needs of users.
Objective 1 — Authentication risk is understood
Applying a risk-based approach to authentication assurance helps to identify the aspects of identification that drive the level of risk. Understanding this enables the development of a wide range of mitigation strategies.
AA1.01 Guidance — risk assessment
Any robust risk assessment process may be used to identify the authentication risk posed. The guidance provided in Assessing identification risk has been developed to improve the quality of this assessment.
A workbook has also been developed to help with undertaking an identification risk assessment and to provide the optimum level of assurance as an output. For a copy, email firstname.lastname@example.org.
If the assessment is being used for assessing the risk of providing an authentication credential, consideration needs to be given to the accumulated risk posed by the reuse of the credential.
Objective 2 — Ensure correct authenticator holder behaviour
For single-factor knowledge and possession Authenticators, there is little that can be done to prevent sharing other than encouraging correct behaviour . Even when knowledge and possession factors are combined, for example a bank card and PIN, the reliance is still on the authenticator holder not to share these.
There are also likely to be different behaviours associated with different types of possession factor Authenticators. The holder may relatively readily share a library card, a door access card or a home computer, but be less likely to share a personal mobile phone.
Authenticators using biometric factors offer more effective mitigation against sharing in most circumstances.
AA2.01 Guidance — terms and conditions
The terms and conditions need to cover the obligations and expected behaviour for the specific Authenticator. For example, a passport holder needs to understand how to keep a passport safe both when travelling and at home. For online authentication, holders may not be fully familiar with the requirements for hardware devices or software implementations.
At level 1, providing explicit terms and conditions is optional. For authentication such as a retail discount card or an online game, the value that the holder places on the service may be enough to ensure correct behaviour.
For level 2 and above, the Party cannot assume that every user will fully understand their obligations, and hence the requirement to explicitly state these.
While a person might understand that they should not share an Authenticator when accessing a service for their personal use, this may not always be as clear for other situations. For example, people might casually share an Authenticator when they want to do something with family and friends, in a work context or on behalf of a group they belong to.
AA2.02 Guidance — reminders of obligations
Terms and conditions communicate obligations during enrolment or Authenticator registration but are likely to become less effective as time goes by and memory of these obligations fade. Therefore, holders need to be reminded about their obligations and expected behaviour, from time to time.
The frequency of reminders will be influenced by:
- the level of assurance
- how often the Authenticator or Credential is renewed (an annual renewal may not need separate reminders)
- awareness of new types of attack that are being used against the Authenticator
- awareness of an increase in compromises within the holder group, related to behaviour.
When the environment changes, it is appropriate to communicate with Authenticator holders to make them aware of current good practice for keeping their Authenticator safe.
AA2.03 Guidance — sharing prevention
There is nothing about a knowledge factor that prevents it from being willingly shared by the Authenticator holder.
The ability to share a possession factor can be restricted, to those in the immediate vicinity of the factor and by the type of possession factor. However, if the holder chooses to share, nothing in the Authenticator itself prevents this.
Biometric factors implemented well, require the holder to be present and participating at the time of authentication.
AA2.04 Guidance — prevention of an indicative behaviour
This control works in conjunction with other limiting controls.
The 30-minute timeout after a maximum of 5 incorrect attempts for knowledge and possession factor challenge responses, still allows for attempts to be resumed. Presentation attack detection of a biometric factor will not allow access by each individual attempt but does not prevent further attempts.
By monitoring a system for repeated sets of consecutive unsuccessful attempts to authenticate by any factor, a suspicious activity can be indicated, and unauthorised access prevented.
Where appropriate to the implementation, up to 3 re-entries could be allowed for the same challenge attempt, for example the same received code for the code receiver method.
AA2.05 Guidance — compromise reporting
Good user behaviour can be encouraged by providing easy and effective means for the holder to report loss, compromise or other issues with an Authenticator.
Often at lower levels like level 1 or 2, an Authenticator can be relatively short-lived or disposable. When this is the case, for example a store discount voucher or a website login for pizza ordering, it may be easier to get the entity to re-enrol rather than support a recovery process to identify the account, bind the entity and establish a new Authenticator
At higher levels like level 3 or 4, it's more likely that the account will be valuable and long-lived — consequently the option of closing the account and requiring reenrolment will not be feasible or will be at a high cost. In these circumstances, there needs to be a process to rebind the Entity to the account and with a new Authenticator. See the Binding Assurance Standard.
At all levels, the processes that follow the loss or compromise needs to be appropriate for the risk of the services, transactions or Entity Information to which it enable access.
Objective 3 — Prevent use of a physically acquired possession factor
For single factor possession Authenticators, there a few ways to prevent physical acquisition other than encouraging the holder to keep the Authenticator safe from theft or unnoticed use by others. A possession factor Authenticator will be more effective if it is highly valued by the user, for example a card for obtaining social benefits or a personal mobile phone.
AA3.01 Guidance — using an additional factor
At higher levels, combining a possession factor with a different factor provides protection against physical acquisition.
Examples of additional factors to possession factors
- A PIN prevents use of a borrowed or stolen bankcard
- A password prevents use of a borrowed or stolen code generator, such as a grid card
- A password prevents use of a borrowed or stolen code receiver, such as a mobile phone, whether it is locked or not.
At level 4, the standard requires that a possession factor is combined with a biometric factor. This is primarily to mitigate against sharing, but it also provides an effective protection against physical acquisition.
Objective 4 — Protect knowledge factor response from being guessed
The use of knowledge factors remains the most widely used form of authentication, especially online, despite longstanding concerns about security and usability. When required to memorise a knowledge factor, human behaviour is often to choose something simple and familiar. The risk of this is that someone else can guess, discover or manipulate disclosure of the response.
Informed commentators are increasingly advocating against requiring longer and more complex responses.
The technical security approach to the threat of guessing is to add more rules to make guessing harder, such as more complex characters and increased length. However, analysis of attacks has shown that the effect of more complicated rules has minimal benefit. Instead, the human behaviour requirements of usability and memorability have been negatively impacted.
The aim of increased knowledge factor response complexity has been driven by an attempt to create higher entropy. Increasing the number of guesses that are needed to get the right response. Higher levels of entropy mitigate against unconstrained brute-force attacks.
However, threats such as keystroke logging, phishing or other forms of manipulated disclosure, and deliberate sharing are not prevented by increased entropy. See Objective 5.
AA4.01 Guidance — knowledge factor complexity
While in recent years , there has been a trend favouring an 8-character minimum length rather than 7, the reasoning behind an 8-character or longer length minimum is one-sided. In theory, a random 8-character combination is harder to guess. However, other factors such as commonality and number of character sets can influence this. For instance, “Tr0ub4dor&3” could take just 3 days to crack, verified by security researchers, while “CorrectHorseBatteryStaple” could take 550 years.
It is most important that knowledge factor responses are memorable. However, the human behaviour response to longer lengths may result in weaker responses. For example, choosing simpler content that can be remembered or creating predictable patterns like adding numbers to the end.
Therefore, it is recommended that upper limits on the length of the response be extended to allow for phrases or strings of words. This also aids memorability and reduces the need to write them down.
For any of the online creation of knowledge factor responses, it is highly recommended that a strength meter or similar feedback mechanism is incorporated. Where higher levels of Authenticator strength are required it is better to employ other strategies than to increase the minimum length of the knowledge factor alone.
AA4.02 Guidance — reduce common responses
The degree to which this control can be undertaken outside online implementations may be limited.
For online implementations, a strength meter can relatively seamlessly handle complex rules, such as disallowing the current 100 most popular responses, such as passwords, even though these meet the more simplistic character set and length constraints. It’s particularly beneficial to provide interactive feedback while the response is being entered which can demonstrate considerations such as part-words being stronger than complete dictionary words.
AA4.03 Guidance — reduce attempts
With retry limits in place, repeated attempts to guess a knowledge factor response are significantly reduced. However, this control needs to be used in conjunction with AA2.04 otherwise it is possible the correct response could be given, with enough time.
Limiting the number of unsuccessful attempts and implementing timeout periods can be made more effective if the authentication holder is notified. Such a notification function simply notifies the holder to determine whether it was the holder’s own attempts or alerts them to notify the service of the suspicious activity.
This notification should be passed via a previously registered communication channel such as Short Message Service (SMS) or email. The notification method should only be able to be modified when the holder is authenticated.
AA4.04 Guidance — using an additional factor
Independent of any length or complexity applied to a knowledge factor, the addition of a separate factor will effectively mitigate against guessing.
Other discovery methods, for example where the knowledge factor response has been written down or is overheard, are covered by Objective 5.
Objective 5 — Preventing manipulation of the holder into disclosing the knowledge factor
Increasing the length of the response has no effect on manipulations attacks that include mechanisms such as key-stroke capture malware, phishing and similar manipulated disclosures, or sharing of responses.
AA5.01 Guidance — using an additional factor>
Where knowledge factors are used on their own, there is little that can be done to prevent disclosure via manipulation other than encouraging the holder to keep the Authenticator safe from anyone else. The holder should be made aware of this requirement via the terms and conditions and reminders as described in Objective 2.
At higher levels, combining a knowledge factor with a different factor provides protection against physical acquisition - for example a PIN cannot be used without the bank card, or a password cannot be used without a code receiving device
At level 4, the standard requires that a knowledge factor is combined with a biometric factor. This not only effectively mitigates against manipulated disclosure but also the active sharing of an Authenticator.
Examples of additional factors to knowledge factors
- A password combined with a code sent to a pre-register mobile device.
- A PIN combined with a reading a magnetic stripe or chip on a card.
- A password combined with an iris scan.
Objective 6 — Protecting against replication, forgery, or spoofing of possession and biometric factors
Possession and biometric factors need to be protected against replication, forgery or spoofing by an attacker including the ability to provide the expected static response or 1 or more dynamic responses.
This Objective covers a wide range of threats against possession and biometric-based Authenticators whether they are presented physically in-person or remotely over a communication channel, such as phone, internet or video link.
Controls AA6.01 to AA6.03 relate to possession factors, while AA6.04 and AA6.05 relate to biometric factors. Therefore, depending on the Authenticator being implemented, only parts of this Objective may apply.
AA6.01 Guidance — forged possession factors
Adding design and security features to physical possession factors make them more difficult to replicate or forge. These features provide indicators to receivers of presented items that enable them to assess if they are fraudulent. The more sophisticated they are, the more effort is required to replicate them but also the greater the skill set required to test them.
More information on physical documents can be found in Using document as evidence.
AA6.02 Guidance — spoofed possession responses
For possession factor Authenticators that involve a non-physical challenge response (both hardware and software devices), there needs to be applicable security safeguards for the technology in place.
Examples of safeguard measures
- For the code generation method, the source value is protected.
- For the code receiver method, the code is not displayed if the holder’s device is locked.
- For the cryptographic key method, the key is protected from being exported.
- For the cryptographic key method, physical input is required to operate to prevent remote access.
The amount of time that a dynamic response remains valid will depend on the method of transmission and the reasonable time it takes to access the response and provide it to the authentication process. A message sent to a phone can be quicker than one sent to an email account. To press a button on a code-generating token can be faster than using references to look up a code on a grid card. This time limit may include an allowance for one or more mistakes to be made during the entering of the response value.
AA6.03 Guidance — complex possession responses
While an allowance is made for a response value to be attempted more than once in case of mistakes during provision to the authentication process, it should not be possible to keep trying to effectively guess the response. Adding complexity to the response mitigates attempts to guess within the time it remains valid.
AA6.04 Guidance — spoofed biometrics
Biometric characteristics do not constitute secrets. They can be obtained online or by recording someone (For example, taking a photograph for facial image, taking a soundbite for voice) with or without their knowledge, lifted from objects someone touches (For example, latent fingerprints), or captured with high resolution images (For example, iris patterns).
Steps need to be taken to detect if copies are being used, especially if the biometric characteristic is being collected remotely, for example, over a video link or phone call rather than in person.
Examples of spoof detection
- Analysing light and shadow in the video image.
- Analysing the pixels in the video image.
- Analysing a voice print for indicators of recording mechanisms.
While presentation attack detection (PAD) technologies can mitigate this threat, additional steps such as limiting the number of consecutive failed authentication attempts or imposing a delay before the next attempt, increasing exponentially with each successive attempt, for example, 1 minute before the following failed attempt, 2 minutes before the second following attempt, and so on, should also be implemented.
AA6.05 Guidance — liveness checking
The Authentication Assurance standard does not explicitly specify what needs to be measured to achieve 90% resistance to presentation attacks. Not only will the potential attacks vary between different forms of biometric Authenticator, but these may also change relatively quickly over time as new exploits are attempted.
A common method to check liveness is to randomise actions or responses used to collect the sample for the comparison process.
Examples of random actions or responses
- Assessing voice comparison on responses to questions where the answer has not been pre-recorded or on the overall conversation. This requires a more comprehensive collection of sample sounds at initial enrolment.
- Assessing facial comparison by requesting the Entity to carry out a series of random actions from a larger set like nodding, shaking and tilting the head, blinking eyes, smiling, frowning, and the like, making it hard for a recording to be used.
The current best minimum practice for resistance to presentation attacks using technology is the use of Clause 12 of ISO/IEC 30107-3 – ISO Standards. However, it is also strongly recommended that communities of practice are used to monitor emerging threats.
Objective 7 — Managing biometric factor probability
For levels of authentication assurance using a biometric single factor, it is assumed that any suitable biometric Authenticator will provide a better confirmation of a returning Entity than an alternative knowledge or possession single factor Authenticator as threats such as guessing, acquisition or sharing are mitigated. However, due to the probabilistic nature of biometric recognition, there is a residual risk that a false positive will occur. This is where a near match to the right holder might pass authentication but is none the less not the correct Entity.
AA7.01 Guidance — reduce false positives
The degree of probability that either a false positive or false negative will occur during the comparison of a biometric characteristic is down to the skill or the person doing the comparison, or the threshold set on an automated system. Neither are currently able to get it right 100% of the time.
Depending on the outcome to be achieved by a biometric recognition system these thresholds can be set very broadly, increasing the percentage of false positives.
Ensure that operators doing manual comparison receive training commensurate with the level being achieved, including training in comparison bias.
To achieve a rate of <0.01% false positive rate, based on a one-to-one comparison of particular groups of Entities can require consideration of the type of biometric characteristic being used.
Examples of inappropriate characteristics
- Fingerprint is not suitable for people who work with their hands in harsh environments.
- Face could be problematic in environments where safety gear or cultural coverings are worn.
- Systems involving touch are not be suitable for environments where hygiene is important, such as medical facilities and food preparation.
- Voice will be difficult where there is a lot of noise or poor telecommunications quality.
AA7.02 Guidance — using an additional factor
Where biometric factors are used on their own, there remains a risk of false positives.
At higher levels, combining a biometric factor with a different factor provides a more precise or binary element to the response.
Examples of additional factors to biometric factors
- A password or PIN response that has a single correct value.
- Card with a chip containing a unique configuration.
Objective 8 — Authentication event can be investigated
An important element of trust in any authentication process is the ability for an Entity or Relying Party to question an event that has occurred. This is especially true if there is any suspicion that the holder was not undertaking the process.
AA8.01 Guidance — investigation
It is important to keep good records, regardless of the way in which authentication assurance is carried out. The ability to investigate the processes is a contributing element to building trust in those processes.
What and how much information is recorded about the processes undertaken will depend on the risk behind the need for enrolling the Entity plus any requirements under legislation, such as the Public Records Act 2005 — New Zealand Legislation.
Additional general guidance
Implementing timeouts in conjunction with attempt limits
While attempt limits are an effective way to stop fraudulent behaviour for many Authenticators, by disabling an account, it does result in some effort required by the rightful Entity and the Relying Party to resolve. Providing some deterrent steps ahead of this is one way to reduce this effort and the disruption it may cause to the service being provided.
The examples below show how the two controls AA2.04 and AA4.03 work in conjunction with each other.
Examples of the impact of combinations
- Level 1 – The responder makes 10 attempts. Then, they wait a minimum of 15 minutes and make a further 10 attempts. After an elapsed time of half an hour they are now able to complete another 10 attempts making a total of 30 consecutive attempts and triggering the account to be disabled pending investigation.
- Level 2 and above – The responder makes 5 attempts. Then, they wait a minimum of 30 minutes and make another 5 attempts before again having to wait 30 minutes. After 2.5 hours, they can make their final 5 attempts before hitting the 30-attempt threshold and triggering the disabling of the account.
- A delay of 12 hours would mean 2.5 days would have to be invested by the responder.
In both these examples the total number of attempts is 30, but the time the responder must invest becomes greater in reflection of the assurance level.
Even if an automated programme is used, which should be addressed by security measures, the likelihood that a response can be correctly guessed in 30 attempts is relatively small – even where the response value has lower entropy.
Contiguous challenging of multiple factors
For multi-factor authentication, it is not necessary for the authentication factors to be implemented using the same communication channel or same device – for example:
- in-person presentation of a passport document (possession factor) and facial image comparison (biometric factor) – single channel
- an online password (knowledge factor) and a separate code generating device (possession factor) – multiple channels and devices.
Authentication mechanisms containing multiple factors need to be challenged in a contiguous manner to effectively ensure the involvement of the same person.
An in-person presentation of a recognised photo ID, such as a passport, clearly combines the document check and the photo check within a single process. Similarly, online entry of a username and password, followed by entry of a code sent by SMS as the next step constitutes a contiguous process.
Any substantial time delay or interruption in the authentication process, that occurs between the challenges has the potential to allow a second party with only part of the authenticator to complete authentication. For example, the holder accesses an online service using a password and carries out several low-risk transactions before leaving their device unattended. Before any timeout occurs, another party selects a high-risk transaction, needing multi-factor authentication. They have previously gained access to the holder’s grid card and photocopied it. If they are only asked for the response to the grid card without the password, the strength provided by the multi-factor Authenticator has not been realised.
If there’s an intention to provide authentication assurance services to other parties, the requirements for Federation Assurance should also be applied. Learn more about Federation Assurance.
The following resources are also related to this topic:
- Authenticator types
- From Very Weak to Very Strong: Analyzing Password-Strength Meters (PDF 439KB)
- CERT Guidance for businesses – CertNZ
Department of Internal Affairs Te Tari Taiwhenua