App protection with PIN

The Mobile Authenticator Studio cryptographic applications can be protected with a PIN code. The PIN is stored in encrypted form with a key that is bound to biometry, and the storage containing the PIN is created with biometric protection enabled. The protection with PIN is defined in the Mobile Authenticator Studio Parameter Sheet. The PIN is used to create a key that encrypts the authenticator secret in the app. Without the correct PIN, the Mobile Authenticator Studio app cannot decrypt the authenticator secret and generate a valid response.

The following algorithm is used to create the secret encrypting key of the authenticator:

Key = PBKDF2 (PRF, Password||Serial Number||Device Data, salt, c, sekLen)

The PBKDF2 parameters must be:

• PRF: SHA-256

• Password||Serial number||Device data: concatenation of the user’s PIN, the serial number of the authenticator, and the device-specific data

• Salt: Fixed data

• C: Configurable number of iterations defined in the Mobile Authenticator Studio Parameter Sheet

• sekLen: key length: 32 bytes

The PIN code for the app is set by the user as part of the activation process and can be changed afterwards at any time. It serves as a key to encrypt the authenticator's secret. If protection with PIN code is enabled, users will be prompted to enter their PIN prior to any response generation. Once set, app protection with PIN cannot be removed.

If a user forgets their PIN, Mobile Authenticator Studio must be reactivated because the authenticator key is no longer usable.

The validation mode of the PIN code is determined by the password security level defined in the configuration of the authenticator:

• Checksum: During the activation process, a checksum of the PIN code is stored on 1 byte in the dynamic vector. In the course of the authenticator life cycle, PIN codes will be tested against that checksum so that only those matching it will be used to decrypt the secret. The checksum allows wrong PIN code collision. Wrong PIN codes with a valid checksum will be used to decrypt the secret but will generate invalid responses. Compared to the no–password-check level, more PIN codes are rejected but a large number still generates wrong responses.

  In case of a PIN change, a wrong old PIN with a correct checksum will collide with the current PIN. The decryption of the authenticator secret will not be correct, and the incorrect secret will be encrypted with the new PIN. The result is a definitive authenticator secret corruption. The authenticator must be re-activated or replaced.

• Hash: During activation, a hash of the PIN is stored on 4 bytes in the dynamic vector. In the course of the authenticator life cycle, PIN codes will be tested against this hash so that only those matching it will be used to decrypt the secret. As the hash is on 4 bytes, fewer PIN codes are matching than with the 1-byte checksum. Compared to the checksum feature, a lot of PIN codes are rejected and only a few generate wrong responses.

  To avoid brute-force attacks, OneSpan strongly recommends using the checksum level. With checksum validation, a wrong PIN may be accepted, which leads to an incorrect decryption of the authenticator keys.

If validation fails and the password fatal counter is not null, no OTP is generated and the password fatal counter is decremented by one from the value defined in the configuration of the authenticator. When this counter is consumed, the password penalty is applied.

The password penalty is the consequent behavior of Mobile Authenticator Studio in case the password fatal counter of a PIN-protected action request has reached 0.

When the user defines a new PIN code during the authenticator activation or the password change process, Mobile Authenticator Studio can be configured to either mask the user input and request a confirmation, or to display the user input. This is defined by the passwordConfirmation attribute of the Functional element in the configuration file.

PIN protection features

Weak PIN

The Mobile Authenticator Studio app is able to detect weak PIN settings. If a user submits a weak PIN, the app will reject it, indicating that the PIN is not strong enough.

If weak PIN control is configured for the authenticator, the following detection rules will apply for weak PIN codes:

• The difference between consecutive digits of the PIN must vary. For example, 12345 is a weak PIN because the difference between the consecutive digits is always +1.

• A row of 0s (N-1 0s for a PIN of N digits) followed by a number (e.g. 00003), or a number followed by a row of 0s (e.g. 2000) are not valid. (This is the ATM mimic.)

• After the PIN has been changed, the new PIN must be different from the old PIN.

111111 is weak

111112 is not weak

123456 is weak

123457 is not weak

000005 is weak

200000 is weak

007000 is not weak

The weak PIN check carried out by the app is optional, and can be enabled when ordering the authenticator licenses in the Mobile Authenticator Studio Parameter Sheet.

PIN change

If PIN change is enabled in the Mobile Authenticator Studio configuration file, the PIN can be changed in the app’s Settings menu at any time. If biometric authentication is enabled, the user is prompted to authenticate with the selected biometric method to successfully change the PIN.

If the PIN is optional as defined in the Mobile Authenticator Studio Parameter Sheet, the users will not be prompted for it during the activation of the authenticator. However, if enabled in the Mobile Authenticator Studio configuration file, the PIN can be set in the app’s Settings menu at any time. To maintain protection of the authenticator, the PIN, once it has been set, can be changed. Resetting the PIN is only possible by reactivating Mobile Authenticator Studio.