Configuration Security Best Practices

This section identifies configuration options and best practices designed to secure the operations of HID Approve.

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.

For further information, see:

Protection policy for iOS/macOS

Protection policy for Android

Protection policy for Windows

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.

Configure Allowed Devices for Service Registration

The HID Approve application allows defining a set of rules restricting the service registration according to the mobile platform characteristics.

You can exclude platforms from Service registration based on the following:

• Specific OS (Android or iOS/macOS)

• Specific OS version or a range of versions (by defining the maximum and minimum values)

• Specific key store mode (software or hardware)

• Specific root state (corresponding to a rooted Android phone or a jailbroken iOS/macOS phone)

When a platform is excluded, a warning is displayed during service registration on the user’s device. This warning can be customized on the server-side.

The "rules" are defined using the following JSON payload for the "provisioning" claim:

• "ruleid" – an ID to identify the rule. Several rules can be added in the JSON (for example, one per outcome).

• "phonestates" – a list of mobile platform characteristics containing of one or several of the following:

  • "os" – defines the OS platform (that is, Android or iOS/macOS)
  • "osversion" – defines the OS platform
  • "keystore" – defines the key store mode (either sw for software or hw for hardware)
  • "isRooted" – defines the rooted/jailbroken state of the device (either true or false)
  • "maxosversion" – defines the maximum value of the range of OS versions
  • "minosversion" – defines the minimum value of the range of OS versions

• "outcome" – defines the result of the rule:

  • deny - provisioning is denied for the device

• "Message" – a customizable warning message displayed to the user when the rule is applied

For Android devices only, it is also possible to define authentication rules to restrict biometric authenticators. If the rule is not defined, by default, only strong (class 3) biometric authenticators are authorized. The rules are defined using the following JSON payload for the "authentication" claim:

• "ruleid" – an ID to identify the rule

• "bioclass" – an integer value of 2 or 3 corresponding to the minimum authorized biometric class security level

• "outcome" – to define the result of the rule

  • Only allow is currently supported

For example, JSON data with two provisioning rules and one authentication rule to allow class 2 biometrics:

"rules": {
	"version": 1,
	"provisioning": [
		{
			"ruleid": 1,
			"phonestates": [
				{
					"os": "Android",
					"osversion": "6",
					"isRooted": "true"
				},
				{
					"os": "Android",
					"keystore": "sw"
				}
			],
			"outcome": "deny",
			"message": "Not allowed to provision for Android version 6 rooted phone or Android device with software key store"
		},
		{
			"ruleid": 2,
			"phonestates": [
				{
					"os": "iOS",
					"maxosversion": "10",
					"minosversion": "9"
				}
			],
			"outcome": "deny",
			"message": "Not allowed to provision for iOS version 9 to 10 "
		}
	],
	"authentication":[
		{
			"ruleid":3,
			"bioclass":2,
			"outcome":"allow"
		}
	]
}

To apply the defined rules with ActivID AS/Appliance:

1. Log on to the ActivID Management Console as a Configuration Manager.
2. Select the Configuration tab.
3. Under Polices, select Authentication and then Device Types.
4. Select the Mobile push based Validation Device type (DT_TDSV4).
5. Paste the .json content into the Policy Rules field and save your changes.

Alternatively, you can define the rules using the Device Type REST API endpoint for either the:

• ActivID AS or ActivID Appliance

• HID Authentication Service

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 Apple Push Notification Service for iOS, Android FCM Google Firebase Cloud Messaging for Android , Windows WNS Microsoft Windows Push Notification Services) are considered significantly more secure than older technologies and should be leveraged when possible.

For further information, see:

Push notification for iOS/macOS

Push notification for Android

Push notification for Windows

Transport Layer Protection

Communication to the HID authentication server/service relies on TLS. For example, with the ActivID Appliance, the server is configured to enforce a strong TLS policy including usage of TLS 1.2 with strong cipher order configuration and server certificate:

• Protocol – TLS 1.2

• Cipher suites:

  • ECDHE-RSA-AES256-GCM-SHA384

  • ECDHE-RSA-AES128-GCM-SHA256

  • ECDHE-RSA-AES256-SHA384

  • ECDHE-RSA-AES128-SHA256

• Server certificate:

  • RSA module size – 2048 bits

  • ECDHE curves – prime256v1, secp384r1

  • ECDHE sizes – 256 ou 384 bits

Certificate Pinning

It is recommended that integrators of the HID Approve SDK implement certificate pinning (RFC7469) to add an extra layer of protection to secure any communication between the integrating mobile application and the server.

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.

For further details, see:

ActivID AS push solution certificate pinning

ActivID Appliance push solution certificate pinning

HID Authentication Service push solution certificate pinning

For further details on implementing this security feature, refer to OWASP recommendations.