Protecting authenticators

The OneSpan authentication technology relies on the fact that a OneSpan customer shares a certain algorithm and certain values with all their end users. Some of these values are cryptographic keys, and must be kept secret by both parties. On the end-user side, the algorithm and values are used to generate a one-time password (OTP) and an electronic signature. On the customer-side, the algorithm and values are used to verify these OTP values and electronic signatures.

Security and confidentiality in the handling of authenticators is of utmost importance. The secret values of the authenticators must under no circumstances be disclosed to third parties, only OneSpan and the customer must know these values. If this is not observed, the secret values are compromised and can be used for attacks. Any indiscretion regarding the secret values thus effectively invalidates all strong authentication efforts.

Delivery of authenticators

After the authenticator has been provisioned with its secret, OneSpan creates a host file that holds the authenticator's secret. OneSpan uses these host files, e.g. the DIGIPASS export file (DPX) and Portable Symmetric Key Container (PSKC) files, to transport the authenticator secrets which are then imported into OneSpan Authentication Server. To protect the secret's confidentiality it is encrypted with a host file transport key. For PIN-protected authenticator products, PIN and PUK files are available. These PIN and PUK files contain the end user secrets that will be used in combination with the authenticators.

OneSpan does not retain the secrets of hardware authenticators of customers by default. This means that OneSpan cannot redeliver the customers' DPX, PSKC, PIN, or PUK files after the initial delivery. Customers who wish that OneSpan retains their secrets must conclude the DIGIPASS Secrets Retention Service contract. For more information, visit https://www.onespan.com/support/security/customer-service or consult your account representative.

Delivery of files and keys

The host files, host file transport keys, PIN/ PUK files and, in case of software authenticators, mobile binary files can be delivered electronically directly to you, or physically via postal service. Tracking information for the delivery is available and can be provided to you upon request. For the delivery, you have several options regarding the file formats (host files, PIN/PUK files, activation code), file protection (host files, host file transport key, PIN file, activation code), delivery channels (CD-ROM via postal service, download via FTP/sFTP or HTTPS,via e-mail, or Connect:Direct).

The mechanisms for protecting and delivering host files, host file keys PIN/PUK-files, and activation codes are important for the security level of the authentication solution. Files containing secrets and their corresponding encryption secret should always be sent via different, independent channels.

For more information, see Protecting host files.

Delivery of software authenticators

You are free to deliver the software to your customers in any way you choose. You can either deliver software to users, or allow them to download the software from a secure site. An activation code is required to activate the software authenticator. This code can be delivered via two methods:

Online delivery

With this method, the activation code is delivered directly to the application that is going to use it. If the activation code is delivered in this way, the user will never see it. This option is available for Mobile Authenticator Studio and the OneSpan Mobile Authenticator app.

Offline delivery

With offline delivery, available for Mobile Authenticator Studio, the activation code is delivered via a mechanism such as email, text message, or fax.

Best practices: Authenticators in general

• Limit authenticators. You can restrict the applicable authenticators via the policy settings. This allows you to restrict the use of authenticators to particular authenticator types and/or authenticator applications based on their names or types.
• Limit authenticators per user. You can restrict the maximum number of assigned authenticators per user for specific authenticator types to the number of devices really needed via the policy settings. If you need to have more than one authenticator provided to your users, limit the number to avoid that too many authenticators (and/or instances) are assigned to or activated for single users. The higher the number of authenticators assigned to a single user, the higher the chances of successful OTP guessing attacks!
• Use authenticator PINs. If you provide authenticators that support PIN protection, enable it.
• Set a (reasonable) user lock threshold. Set the number of invalid logon attempts that are allowed before a user account is locked to avoid brute-force attacks.

Best practices: Handling lost authenticators

When an end user reports a lost authenticator, in addition to your organisation's security policy for suspicious authentication attempts, we recommend instructing your help desk administrators to proceed as follows:

• Confirm the user identity. Confirm the user's identity via any document or information available to you. Also retrieve information from the user linked to their account only you and the user can know (e.g. by asking agreed security passphrases, or, in lack thereof, general questions which only the user can know the answer and you have the means to verify).
• Investigate how and when the authenticator was lost. Question the user about the circumstances and time that they lost their authenticator.
• Disable the authenticator. Disable the relevant authenticator in OneSpan Authentication Server by either deleting the authenticator or deactivating the affected application of the authenticator.
• Record the information. Record the date of the incident and audit the logs for any attempts to authenticate with the affected authenticator.