Security Best Practices for Push Authentication

The following sections provide guidelines on securing the push-based operations of the ActivID AS and HID Approve application, specifically concerning the password policy, mobile devices, secure communications and certificate pinning.

Server-Side Best Practices

The SSL handshake between HID Approve and the ActivID AS (or Reverse Proxy) is a key factor in the Push platform configuration.

In particular, the following guidelines concern important configuration practices:

Avoid using a self-signed server SSL certificate

A server SSL certificate issued by a Certificate Authority should be used instead of a Self-Signed Certificate for the ActivID AS (or Reverse Proxy).

Avoid using unknown certificate authorities

The Certificate Authority for the ActivID AS (or Reverse Proxy) should be known to devices.

Check there are no missing intermediate certificates

All intermediate certificates in the certificate chain should be included in the ActivID AS (or Reverse Proxy) trust store. Use a certificate bundle (p7b with the SSL server certificate plus intermediate CA certificates) when importing the chain into the ActivID AS (or Reverse Proxy).

Verify the hostname used in the activation URL

The HID Approve Activation URL hostname should match that of the ActivID AS (or Reverse Proxy) (or alternative names as defined in the SSL certificate).

Make sure that Certificate Pinning is configured correctly

Certificate pinning, or public key pinning, helps to protect end users by restricting which server certificates are considered valid. This limits the risk of man-in-the-middle (MITM) eavesdropping attacks by, instead of allowing any trusted certificate to be used, the connecting application is configured to accept only genuine certificates that match an expected "pin" hash value.

It is recommended that integrators implement certificate pinning (RFC7469) to add an extra layer of protection to secure any communication between the integrating mobile application and the server. For further details on implementing this security feature, refer to the OWASP recommendations.

The Certificate Pinning configuration in the customization file (that is, server public key hash value) should match the ActivID AS (or Reverse Proxy) configuration.

You should also anticipate the rollover timing of the certificates to avoid service disruption.

For further information, see Customize the Application Certificate Pinning Behavior.

Enforce Strong TLS cipher suites

Communication to the ActivID AS relies on TLS. The ActivID AS is configured to enforce a strong TLS policy including usage of TLS 1.2 with strong cipher order configuration and server certificate.
For Android devices
- Android 7.x and later requires that the ActivID Server SSL Certificate is issued by a system Trusted Certification Authority (for example, IdenTrust® can be used as it is embedded in the application).
- It is recommended to upgrade to the latest version of Google Play Services.
- For an optimum SSL connection with the server (or the Reverse Proxy), make sure that the following cipher suites are included in the list of cipher suites on the server side (in the Application Server SSL configuration or Reverse Proxy Configuration):
  - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
For iOS devices
- iOS 10.0 and later require that the ActivID AS SSL Certificate meets the following App Transport Security (ATS) requirements:
  - Signed with a 2048-bit RSA key or 256-bit ECC key at a minimum.
  - Uses SHA-2 Certificate Signature hash algorithm with a SHA-256 fingerprint at a minimum.
  - Issued by a CA whose root certificate is incorporated into the device operating system or by a trusted root CA installed by the user on the device.
  - Used on a TLS 1.2 connection with either the AES-128 or AES-256 symmetric ciphers, and with a cipher suite supporting PFS through ECDHE key exchange.
- iOS 10.3.x and later specifically requires that the user select the trusted root CA certificate in the Certificate Trust Settings (in the About menu under General Settings) to enable full trust for root certificates installed by the user.
To diagnose potential SSL Handshake issues, you can use OpenSSL to test the SSL connection:

openssl s_client –connect <hostname:<port>

Key Protection Configuration Best Practices

The following diagram provides an overview of the key protection configuration for the Push solution.

Password Policy Recommendations

HID Approve supports a very rich set of policies to protect the mobile credentials. The following sections provide recommendations for a strong password policy.

Use a Password for All Keys (Except Session Transport Key)

Second factor is an important element of key protection, regardless if the mobile is compromised or under attack. The attacker will not be able to decrypt the keys if it is also protected by a password. In an enterprise deployment, password mode should be enforced for all users.

Configure a Reasonable Password Length and Restrictions

It is important to find the right balance between security best practices and user convenience. Useful guidelines on password policy can be found in NIST 800-63B.

The HID Global default policy balances security and usability and can be used as a starting point for defining your own security policy.

It is defined as follows:

Minimum length = 8 characters
Maximum length = 64 characters
Restrictions = none (can contain digits, upper or lower case characters, non-alphabetical characters,…)
Password History = 1
Minimum Age = 0 day
Maximum Age = 0 days (never expires)
Lock Policy = Delay

Configure Password with Lock or Delay Policy

To protect against an attacker using brute force to guess passwords, a traditional approach is to lock the password after a certain number of failed attempts. This approach, while secure, does have a downside as it might allow attackers to create a DOS attack by entering wrong passwords.

Consequently, it is inconvenient for both the service provider and users as keys will need to be re-issued if the password is locked. This might also lead to security concerns as key provisioning generally represents an activity associated with a higher-risk profile.

Therefore, it is recommended that the delay policy is used instead. After a failed attempt, the delay policy forces the user to wait for a short period of time before attempting to authenticate again. The delay interval doubles at each failed attempt until the correct password is supplied. This minimizes the impact on the overall user experience, while effectively preventing brute-force attacks.

The delay policy is also a recommendation of NIST.

Configure Password with Silent Lock Policy

To provide an alternative to the lock or delay policies, the silent lock policy can be used to add extra security against offline brute-force attacks on the mobile device.

Any offline password authentication errors are suppressed, and cryptographic operations will be silently carried out using a false key. Therefore preventing the negative use-case from being easily identified and enabling auditing, validation, and blocking to be delegated to server-side controls (such as exhausting the failed authentication counter).

For example:

For OTP - a bad password will yield a bad OTP (attempting consecutive incorrect OTPs will lead to a blocked account on the server).

The end user will not be notified if an invalid password is entered.

For push-based validation - a bad password will increment the failure counter on the server (consecutive incorrect passwords will lead to a blocked account).

The end user will be notified of the failed operation after performing a server validation.

For key renewal - a bad password will increment the failure counter on the server (consecutive incorrect passwords will lead to a blocked account).

The end user will be notified of the failed operation after performing a server validation.

Note:

By design, when used in conjunction with password-caching or the BioPasswordPolicy, an invalid password will be silently accepted. Also, password expiration (maximum age) is not supported and will be ignored with the silent lock policy.
As a prerequisite to using the lock policy, you need to define an additional "Mobile Operation Protection Key" in the Credential Type and add it to the "Container Profile" for the Device type.

Force Change Password and Define a Password History

Password expiry periods and password history force users to change their passwords at regular intervals and prevent users from reusing old passwords. While this can be an effective method to limit the damage caused by compromised passwords, password expiration can also be a source of frustration to users, who are often required to create and remember new passwords every few months for dozens of accounts.

Studies have shown that this can lead to users using the same passwords for many accounts, which can also pose an adverse effect.

The policy for password expiry, password length, and password history should be defined with care and special consideration towards the user experience to avoid degrading the overall security of the solution.

Configurable Policy

HID Global realizes that industry recommendations evolve over time and might depend on local regulations or standards. The flexible password configuration can be used to adapt the security requirements as these standards evolve to address specific customer requirements.

For example, the current NIST 800-63-3 standard does not recommend overly complex password restrictions because they effectively lead to users selecting predictable passwords (for example, Password1 if the constraint includes one upper case and one digit). This policy can be achieved by relaxing the restrictions on the password accordingly.

Conversely, it is also possible to change the password policy to follow the more stringent directives such as the ANSSI directives.

User Awareness

Instruct all users to keep their passwords secure and to never share their passwords with anyone.

Selection of Mobile Devices

It is strongly recommended to keep mobile operating systems up-to-date to benefit from the latest security fixes.

For Android, it is recommended that you use the latest OS versions and hardware devices with TEE support for the highest level of protection.

In general, it is recommended that you use licensed mobile devices that are part of the Google certified Play Protect program as this guarantees that the device is updated with latest platform security fixes available.

Protecting Mobile Devices

It is recommended that the device PIN or device password is enabled on the mobile or tablet devices.

This protection provides an additional layer of defense to the application-level policy. Additionally, this adds an additional level of protection to the keystore/keychains on the device.

Registration Code

Entropy Recommendations

The registration code policy is configurable.

It is recommended that the registration code is 10 characters in length and with an alphabet size of 94 characters (ASCII) to provide sufficient entropy for the key generation process.

Method for Sending Initial Registration Codes

The initial registration code can be sent to users via different means and will impact the overall level of security:

Manual entry – The registration code might be intercepted by an attacker when sent to user.

Instruct all users to keep their registration code secure and to never tell anyone.

Once used, the registration code should be removed/deleted from any media on which it is stored (paper, email, etc.).

QR code – This is a relatively secure solution and convenient to the user. There is a possible risk that a displayed QR code be intercepted and used to personalize a hacker's device.

It is recommended that access to the registration/personalization workflow requires user authentication at the web application level providing the registration service.

Another recommendation is that the web page exposing the QR code should be protected against standard web session hijacking attacks (CSRF, XSS, etc.).

For even higher security, you can use a more secure delivery of the QR code (for example, a hard copy sent via registered post).

Out-of-Band – Sending the registration code over a separate channel significantly increases security as the attacker must attack both channels.

Note: Not all OOB channels are equally secure. The security industry now considers email and SMS (see FIPS 800-63-3) as insecure means of communication relating to 2-factor authentication and care should be taken when employing these methods.

By contrast, mobile notifications (Apple APN, Android FCM , Windows WNS) are considered significantly more secure than older technologies and should be leveraged when possible.