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

Guidance for Authentication

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.

Assessing identification risk

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 identity@dia.govt.nz.

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.

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

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: Entity binding and Authenticator strength are consistent 

It is important to ensure the Entity is the rightful claimant of the Entity Information before establishing an Authenticator and registering it in Entity Information. This is an avenue 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.

If this is not possible, either a temporary binding mechanism can be used to bridge the gap or the Entity Binding process needs to be repeated. 

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

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.

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.

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

Information to allow an Authenticator’s status to be maintained can include, status indicators, dates, and other flags that the Access Management system can use to determine if attempts to use the Authenticator should be accepted, even if the responses to the challenges are correct.

AA5.02 Guidance – Authenticator status

Typical Authenticator statuses can include: active, suspended, expired and revoked. Changes to the status can be initiated by the organisation or the Entity. Examples include, business rules, detection of fraud, the reporting of a lost or stolen Authenticator, or other unauthorised access to Entity Information.

The information to allow an Authenticator’s registration status to be maintained can include, status indicators, dates, and other flags that the access management system can use to determine if attempts to use the Authenticator should be accepted.

AA5.03 Guidance – Authenticator registration status

The Relying Party needs to identify which registration statuses are to prevent access to the account or system. 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

What and how much information is recorded about the establishment 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.

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

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

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

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.

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

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

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

Objective 8: 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.

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

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 (both 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. 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.

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

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

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 10: 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.

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

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

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.

Related advice

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

Contact

Te Tari Taiwhenua Department of Internal Affairs
Email: identity@dia.govt.nz