Password protection

The Mobile Authenticator Studio cryptographic applications can be protected by a local password. Password protection is defined in the Mobile Authenticator Studio Parameter Sheet. The user’s password is never stored by Mobile Authenticator Studio, but it is used to create a key that encrypts the authenticator secret in the app. Without the correct password, 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 local password is set by the end 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 password protection is enabled, users will be prompted to enter their password prior to any response generation. Once set, password protection cannot be removed.

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

The minimum and maximum password lengths are specified in the Mobile Authenticator Studio Parameter Sheet. These parameters are part of the authenticator's static vector.

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

• No password check: Each password is used as-is to decrypt the authenticator secret. Only the password that is provided during the activation of the authenticator to encrypt the authenticator secret will generate a correct OTP or signature. Other passwords will generate invalid responses.  his method fully relies on the server lock functionality, which can be activated in the settings of the OneSpan server solution. For more information, refer to the OneSpan server solution documentation.

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

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

• Hash: During activation, a hash of the password is stored on 4 bytes in the dynamic vector. In the course of the authenticator life cycle, passwords 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 passwords are matching than with the 1-byte checksum. Compared to the checksum feature, a lot of passwords 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 password 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 password-protected action request has reached 0.

When defining a new password 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.

Password protection features

Weak password

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

If weak password control is configured for the authenticator, the following detection rules will apply for weak passwords:

• The difference between consecutive digits of the password must vary. For example, 12345 is a weak password 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 password has been changed, the new password must be different from the old password.

 

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 local password check carried out by the app is optional, and can be enabled when ordering the authenticator licenses in the Mobile Authenticator Studio Parameter Sheet.

Password caching

For user friendliness, the Mobile Authenticator Studio app can cache the password for a certain period of time. It can be configured in the global password section of the Mobile Authenticator Studioconfiguration file. If the password is cached, users will need to enter it once, and will not be prompted to enter it again until the configured expiration period has elapsed, or until the app is closed. The expiration period is reset each time a key is pressed. During the caching period, the password is encrypted with a device-unique key. For more information, see Appendix A: Device-unique data.

Password input

Users type the local password for the first time during the activation of the authenticator. To emphasize that the local password is a key security feature, the Mobile Authenticator Studio app can be configured to prompt for the password on a dedicated screen. If this option is not configured, users will continue to enter the local password along with other activation data.

There are two ways to enter the local password:

• as single data in clear text, where users can see the characters

• as two-masked data, where users cannot see the characters but are prompted to type the password twice for confirmation.

Password change

If enabled in the Mobile Authenticator Studio configuration file, the local password can be changed in the app’s Settings menu at any time. The local password is not stored by the app.

If the local password 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 local password can be set in the app’s Settings menu at any time. To maintain protection of the authenticator, the local password, once it has been set, can be changed but cannot be reset.