Security Best Practices for Push Authentication

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

    • 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

    • 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

    • iOS 10.0 and later require that the ActivID Server 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>

Client-Side Best Practices

To secure the operations of the HID Approve application, it recommended that you apply the HID Approve SDK best practices concerning the password policy, mobile devices, secure communications and certificate pinning.

Key Protection Configuration Best Practices

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

Click on the relevant zones to access further information about a specific configuration element.

See also:

Security Best Practices