Introduction

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.

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.

Entities can be either a person and non-person (for example, organisations, animals, property, and machines). This guidance is primarily informed by threats and controls for person entities.

While person entities can utilise all 3 factor types, non-person entities generally use only 2 — possession (‘something they have’) and biometric (‘something they are’). A non-person entity cannot be independently challenged for a knowledge factor (‘something they know’).

When the Entity is not a person, then ‘something they are’ needs to be a characteristic of its physical presence (for instance, a machine can have a unique code burnt into a component at manufacture and not subsequently able to be changed). Non-person entities that are machines can also possess something which is securely stored in software such as a certificate in its firmware. In this example, a machine cannot possess something it knows without sharing this knowledge with a programmer.

General information on the types and forms of these Authenticators can be found in the guidance on Authenticator types.

Definitions for key terms used in this guidance can be found in Identification terminology.

This living guidance will evolve and expand over time to meet the needs of users.

Guidance for Authentication

Authentication assurance is the process of confirming to a level of assurance that an Entity remains connected to the account or record that contains the set of Entity’s Information.

An Entity with an Authenticator is called an Authenticator holder, this is the Entity to which an Authenticator was initially bound, the ‘rightful holder’.

Objective 1: Authentication risk is understood

Applying a risk-based approach to authentication assurance helps to identify the aspects of authentication 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. Guidance and tools have also been developed to help with undertaking an identification risk assessment and to provide the optimum level of assurance as an output.

Assessing identification risk

If the assessment is being used for assessing the risk of providing an Authenticator for use across many contexts, consideration needs to be given to the accumulated risk posed by the reuse of such an Authenticator.

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 more 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.

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 these considerations:

• the level of assurance assessed
• 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 there are changes, it’s appropriate to communicate with Authenticator holders to make them aware of current good practice for keeping their Authenticator safe.

AA2.03 Guidance — prevention of sharing

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, when implemented well, require the holder to be present and participating at the time of authentication. For sessions that are remote and not in-person, this means that liveness detection and other protections need to be in place. Though coercion is still possible, this is described in counter fraud guidance.

Counter fraud techniques

AA2.04 Guidance — prevention of an indicative behaviour

This control works in conjunction with other limiting controls, such as AA7.03.

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 ordering pizza) 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 higher cost. In these circumstances there needs to be a process to rebind the Entity to the account and with a new Authenticator. Refer to the Binding Assurance Standard for rebinding Entities.

At all levels, the processes that follow the loss or compromise of an Authenticator need to be appropriate for the risk of the services, transactions or Entity Information to which it enables access.

Objective 3: Entity binding and Authenticator strength are consistent

It’s important to ensure the Entity is the rightful claimant of the Entity Information before establishing an Authenticator and registering that Authenticator as part of Entity Information. Failure to establish that the Entity is the rightful claimant creates an opportunity for the takeover of Entity Information. It can also increase the likelihood of the wrong Entity Information being used.

As the role of the Authenticator is to reconfirm the Entity’s connection to their Entity Information each time Entity Information is used, it needs to be consistent with the level of Entity Binding that was done.

AA3.01 Guidance — confirm Entity Binding

The easiest method is to ensure Entity Binding and establishment of an Authenticator occur within the same transaction session. For example, information collection, binding and establishment of an Authenticator are all part of one continuous process.

Where an Authenticator has not been issued when the Entity Information and Entity Binding occurred, establishment of an Authenticator is a separate transaction.

Repeating Entity Binding needs enough distinct attributes in Entity Information to be re-bound to ensure correct ownership of the account in this circumstance. This process typically relies on the using the Authenticator in a Credential from another context to do this.

Sometimes a temporary Authenticator can be used to represent the Entity Binding process having previously been undertaken, provided it has the same level of assurance as the new Authenticator. The temporary Authenticator can be used to bridge the gap to prevent the Entity Binding process being repeated.

Where there have been other Authenticators registered, these can be used to add new Authenticators at the same or lower levels.

Using an existing Authenticator to reconnect the Entity to their Entity Information only applies when the context has an existing Authenticator in place for another delivery channel (for example, using an Authenticator for the phone channel to reconnect the Entity for an interaction online or in-person).

Presenting several lower-strength Authenticators is not an adequate substitute for one equal or higher-level Authenticator.

AA3.02 Guidance — levels are consistent

In some contexts, multiple Authenticators of differing levels can be added to reflect usability when accessing transactions of differing risk levels. In this case at least one Authenticator should reflect the level of Entity Binding.

Processes such as account restoration, Authenticator resets or adding second factors need to avoid relying on Authenticators with lower levels of assurance.

Objective 4: Entity can control Authenticator

If an Entity has not been challenged to respond to an Authenticator during its establishment, it can provide a poor customer experience if they are then unable to respond at the first authentication event.

Failing to check that the Entity is in control of an Authenticator also removes an opportunity to detect if the Entity is being coerced to add an Authenticator controlled by someone else.

AA4.01 Guidance — control of Authenticator

The type of Authenticator will determine when the testing of control of an Authenticator occurs in the overall process of adding an Authenticator. The important thing is that the ability to authenticate using the Authenticator does not become active until both the registration and test of control have been completed.

AA4.02 Guidance — check for compromised Authenticators

A compromised Authenticator is one that has been recorded as being lost, stolen or misused. It can also include Authenticators that have been revoked, where this is not able to be detected as part of the Authentication process.

There are various registers and services available for undertaking these checks, though many are only available to certain sectors.

Objective 5: Authenticator registration status is maintained

Authenticator Registration is the recording of information about an Authenticator so it can be used as a mechanism for recognising the Entity when they return to the context. Information about the Authenticator forms part of Entity Information.

The lifecycles of Authenticators, Entities and Entity Information are all independent. Authenticators can also be reused in multiple contexts and are therefore connected to different instances of Entity Information.

The Authenticator Registration status provides information to the Authentication process and/or an access management system as to whether an Authenticator should be accepted for that context. This is irrespective of whether the responses to challenges are successful or not.

AA5.01 Guidance — record Authenticator

Information about an Authenticator can include reference numbers and identifiers for the Authenticator.

Where the information includes the answers to knowledge factors (for example, passwords and PINs) appropriate measures should be taken to protect this information. Refer to Information Security specialists for more guidance on this.

AA5.02 Guidance — Authenticator registration status

Typical Authenticator statuses can include

• active
• suspended
• expired
• revoked.

Changes to the status can be initiated by the organisation or the Entity.

The information to allow an Authenticator’s registration status to be maintained can include:

• status indicators
• dates
• other flags.

This information can be used by the access management system to determine if attempts to use the Authenticator should be accepted, even if the responses to the challenges are correct.

It’s crucial that when an Authenticator is reset the level of assurance for the reset process is the same level as the Authenticator first established and any replacement.

AA5.03 Guidance — Authentication blocking

The provider of the authentication solution needs to identify which registration statuses are to prevent access to the account, system, Credential or facilitation mechanism. Each authentication event needs to check for these statuses and fail the attempt to authenticate, even if the Entity has responded correctly to the challenges.

AA5.04 Guidance — expiry

Setting an expiry date on Authentication Registration is an ideal way to initiate the rechecking of Authenticators, Authenticator Control and Entity Binding processes.

Objective 6: Authentication events 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.

AA6.01 Guidance — establishment process investigation

Information recorded to help with investigation of the process to establish an Authenticators will include the date and time the Authenticator was established.

Other information may include the method used to re-establish binding, such as whether Entity Binding was repeated and on which attributes or if another Authenticator was used.

Where a Credential from another context is used, these are not to be copied. Information about the type and nature of the Credential is sufficient.

What and how much information is recorded about the establishment processes undertaken will also depend on the risk behind the need for enrolling the Entity plus any requirements under legislation, such as the Public Records Act 2005 for government agencies.

Public Records Act 2005 — New Zealand Legislation

AA6.02 Guidance — authentication event investigation

As with the Authenticator establishment process, information about each authentication event also needs to be stored. This includes the date, time and other metadata that may be available.

Guidance for Authenticator strength by factor

Objective 7: Protect knowledge factor response from being guessed or discovered

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. Entropy in this case involves increasing the number of guesses that are needed to get the right response. Higher levels of entropy only mitigate against unconstrained brute-force attacks.

Threats such as keystroke logging, phishing, or other forms of manipulated disclosure and deliberate sharing are not prevented by increasing entropy.

AA7.01 Guidance — knowledge factor complexity

In recent years, there has been a trend favouring an 8-character minimum length or longer. In theory, a random 8-character combination is harder to guess than a shorter one. 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.

Forget Everything You Know About Passwords, Says Man Who Made Password Rules — NBC News

It’s 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.

It’s also important that knowledge factor responses are only known to the Authenticator holder and potentially the authenticating party, if it’s a shared secret.

This need for secrecy also applies to security questions. Information that is known to other parties (for example, your favourite colour, your first pet's name) do not qualify as shared secrets. Nor do answers that can be obtained by other means (for example, ‘What is your mother's maiden name?’ which can be answered by anyone who has a copy of the Authenticator holder’s birth certificate).

It’s recommended that upper limits on the length of the response be extended to allow for phrases or strings of words. This is called a passphrase compared to shorter passwords. Passphrases aid memorability and reduce the need to write them down.

For creation of knowledge factor responses online, it’s highly recommended that a strength meter or similar feedback mechanism is incorporated to indicate to the Authenticator holder the comparable strength of their knowledge factor.

Where higher levels of Authenticator strength are required, it’s better to employ other strategies than to increase the minimum length of the knowledge factor alone.

AA7.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 passwords
• specific patterns of characters grouped together on a keyboard or phone screen (for example ‘qwerty’)
• incorporating the user’s account name or the name of the service for the account.

Noting that these meet the more simplistic character set and length constraints.

A list of commonly used passwords and specific phrases that are not allowed can be added into a deny list (also called a block list) where applicable.

List of the most common passwords — Wikipedia

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.

AA7.03 Guidance — reduce attempts

With retry limits in place, repeated attempts to guess a knowledge factor response are significantly reduced. This control needs to be used in conjunction with AA2.04, otherwise it’s 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 a Short Message Service (SMS) or email. The notification method should only be able to be modified when the holder is authenticated.

AA7.04 Guidance — using an additional factor

Where knowledge factors are used on their own, there is little that can be done to prevent disclosure by manipulation other than encouraging the holder to keep the Authenticator safe from anyone else. The holder should be made aware of this requirement in the terms and conditions, and reminders of those terms and conditions 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, 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.

Objective 8: Prevent use of a physically acquired possession factor

For single factor possession Authenticators, there 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’s highly valued by the holder (for example, a card for obtaining social benefits or a personal mobile phone).

AA8.01 Guidance — using an additional factor

At higher levels, combining a possession factor with a different factor provides protection against physical acquisition.

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 9: 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 AA9.01 to AA9.03 relate to possession factors, while AA9.04 and AA9.05 relate to biometric factors. Therefore, depending on the Authenticator being implemented, only parts of this Objective may apply.

AA9.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 documents as evidence.

AA9.02 Guidance — spoofed possession responses

For possession factor Authenticators that involve a non-physical challenge response (includes lookup codes, hardware and software devices), there needs to be applicable security safeguards for the technology in place.

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.

This time limit may include an allowance for one or more mistakes to be made during the entering of the response value.

AA9.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.

AA9.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 or fakes 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).

While presentation attack detection (PAD) technologies can help to mitigate this threat, additional steps such as limiting the number of consecutive failed authentication attempts or imposing a delay before the next attempt (with the delay 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) can be implemented for higher levels of assurance.

As the use of AI to create more realistic biometric spoofs increases, consideration needs to be given to using biometric characteristics that are not as available (for example, palm print, retina, vein topography). The higher the level of assurance required for the Authenticator will guide whether a biometric characteristic that is less available to AI technology is more appropriate.

AA9.05 Guidance — liveness checking

There are 2 points when liveness is relevant, firstly when the initial biometric sample is collected and secondly when a subsequent biometric sample is collected for the comparison process.

When biometric factors are used in-person, liveness is usually a given. Liveness in automated recognition systems or when collected remotely require additional steps to be taken.

The Authentication Assurance standard does not explicitly specify what needs to be measured to achieve 90% resistance to presentation attacks as this will vary depending on the biometric characteristic used.

A common method to check liveness is to randomise actions or responses used to collect the sample for the comparison process.

The current best minimum practice for resistance to presentation attacks using technology is the use of ISO/IEC 30107-3 — ISO Standards.

However, it’s also strongly recommended that communities of practice are used to monitor emerging threats, not yet addressed in standards.

Liveness checking is especially important at level 3 where a biometric factor can be used on its own, as there is no compensating additional authentication factor.

Biometric standards and resources

Independent assessment of the performance of biometric solutions for presentation attack detection and liveness checking are desirable.

The following are websites for organisations that support good practice use of biometric technologies:

• International Standards Organisation (ISO) list of biometric standards
• United States National Institute of Standards and Technology (NIST) Biometric programme
• Biometrics Institute

Objective 10: Managing biometric factor probability

For levels of authentication assurance using a biometric single factor, it’s 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 a biometric factor can mitigate threats such as guessing, acquisition or sharing. 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 the near match is not the correct Entity.

AA10.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 of 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 this threshold 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, this can require consideration of the type of biometric characteristic being used.

AA10.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.

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 authentication provider 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 AA7.03 work in conjunction with each other.

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’s not necessary for the authentication factors to be implemented using the same communication channel or same device.

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 Credential, such as a passport, clearly combines the document check and the photo check within a single process. Similarly, online entry of a 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.

Resetting Authenticators

Authenticator resets may happen when an Authenticator fails and either:

• A new Authenticator needs to be established or
• The existing Authenticator’s registration status needs to be reactivated.

An Authenticator reset may involve using an alternate Authenticator with either a different or another version of the same factor.

Authenticator resets need to rely on a process that is the same level of assurance as the original failed Authenticator, even if it’s not the primary Authenticator the holder uses.

Regardless of which factor is used, fraud is persistent and Authenticators have risk. Counter fraud techniques can be used to add additional actions to increase effectiveness of authentication solutions.

Counter fraud techniques

Contact

Government Digital Delivery Agency
Email: idmstandards@gdda.govt.nz