Authentication Methods

User authentication requested by the Orchestration SDK can take place using one of the following methods:

No password

If the authentication method is No password, no user action is required for the completion of the process.

Password

If the authentication method is password, the Orchestration SDK displays a virtual keypad or call the password user authentication flow, and the user needs to enter their password.

The texts displayed in the dialog and other graphical elements (i.e. text, colors, icons) are customizable. For more information, see Integrating the Orchestration SDK.

Biometric

If the authentication method is biometric recognition, the Orchestration SDK displays a dialog prompting the biometric scanner of the device. The Fallback button provided by the Biometric Sensor SDK is not available in the biometric dialog.

The texts displayed in the dialog are customizable. All other graphical elements (i.e. text, colors, icons) cannot be customized. For more information, see Integrating the Orchestration SDK.

External user authentication

Introduction

It is possible to override the user authentication. Instead of displaying the integrated Orchestration user authentication, the Orchestration SDK will call a specific callback to inform the Customer Mobile Application that such an authentication is required. In this call, the type of authentication will be indicated. For now only password is available. Below you will find some best practices for this kind of authentication.

If an activation was done using an external password, it will have to be provided to change the password.

The input for the PASSWORD authentication is not stored by the Orchestration SDK. This should never be store in the Customer Mobile Application.

Usage

User authentication flow

New APIs are created for Swift users of the iOS SDK. For more information, refer to the Xcode API documentation on UserAuthenticationDelegate for this workflow.

1. The Customer Mobile Application registers a UserAuthenticationCallback and the different user authentication methods that will be overridden.

2. The Orchestration SDK informs the Customer Mobile Application, that a user authentication is required. The following information will be provided:

   • Type of user authentication.

   • A Boolean that indicates if this is for enrollment purposes.

   • A callback to send back the user input.

3. The Customer Mobile Application presents the requested authentication to the user.

4. The user identifies themselves via the Customer Mobile Application.

5. The Customer Mobile Application sends the user input back to the Orchestration SDK.

6. (OPTIONAL) The Orchestration SDK validates the provided input. For example the password should respect the weak password rules of Digipass SDK.

7. (OPTIONAL) The user input can be used to derive the secret stored in the Digipass SDK. , This way, it can  only be used when the user provides the same input.

Password input best practices

Mobile apps often handle sensitive information in the form of passwords. The following recommendations outline the security precautions that should be taken when entering passwords into mobile apps.

Build an in-house keypad (do not use one of the inbuilt keyboards of the device)

Using a custom keypad that is part of the app, prevents attacks using malicious keyboards or generic keyboards sniffers. Third-party keyboards may hide malicious functionalities and can be used to steal passwords. For this reason, they should not be used for password input.

When using an in-house keypad, consider randomizing the position of the keys in the keypad

This security measure will make event grabbing attacks less likely.

Do not allow copying of the password from its input field

If the password is entered in an input field, make sure it cannot be copied to the clipboard.

Use password text fields that hide the value of the password

If the password is entered in an input field, ensure that the password is masked  (e.g., screen displays this format “****”). This security measure prevents attackers from reading the password over the shoulder or from capturing the password via screenshot.

Avoid the use of WebViews for password input

WebViews present additional security risks and should not be used for the input of sensitive information.

Clear passwords in memory as soon as they are no longer needed

Passwords should reside in memory as short as possible.

This means that the object used for storing the password in memory should be clearable (e.g., in Java passwords should be stored in Byte arrays instead of Strings). Once the password is no longer required, the object should be actively cleared (e.g., by zeroing the bytes in the array).

Validate the input before storing it in the password object in memory

In case one of the inbuilt device keyboards is used (and not an in-house keypad), the input from the keyboards should be sanitized before accepting it. Note that this is not the same as checking against a password policy. This is just to ensure that no invalid characters are entered in the input field.

Validate the password output before sending it to a downstream SDK or API call

Although it is the responsibility of the downstream SDK or API to sanitize its inputs, it is a good practice to also sanitize the output before using it in and SDK or API call. For example, the password could be validated against a list of acceptable characters and a maximum length.