- 23 Oct 2024
- 7 Minutes à lire
- SombreLumière
Digipass protection
- Mis à jour le 23 Oct 2024
- 7 Minutes à lire
- SombreLumière
The Digipass dynamic vector contains Digipass secrets that must be protected against attackers. The Digipass SDK provides two methods to protect the sensitive Digipass data:
Delegated protection with an external dynamic vector-encrypting key
If the Digipass configuration does not include password protection and, you do not use a dynamic vector-encrypting key when integrating the Digipass SDK, a default password based on the static vector master key will be used internally to protect the secret. If a password is provided to any Digipass SDK entry point, an error will be produced.
Protection starts after the activation process, once the secret has been extracted from the activation code and stored in the dynamic vector.
Neither the encrypting key nor the Digipass password is stored by the Digipass SDK in the dynamic vector.
Delegated protection
The Triple Data Encryption Standard (3DES) key used to protect the Digipass secret in the dynamic vector is provided by the application that integrates the Digipass SDK. The management of this key is delegated to you during the integration of the Digipass SDK.
Activation with delegated protection (overview)
In Activation with delegated protection (overview), the application integrating the SDK manages its own dynamic vector-encrypting key. This key must be provided during the activation process and afterward for each call to the SDK. Without this key, the dynamic vector cannot be used, and the Digipass authenticator needs to be reactivated.
The dynamic vector-encrypting key is not controlled by the Digipass SDK. Thus, an invalid encrypting key will lead to an incorrect decryption of the Digipass secret and, consequently, to an invalid response. The Digipass SDK does not manage a lock mechanism if it is integrated with delegated protection.
This dynamic vector-encrypting key ensures that only the application owning the key is able to use the Digipass authenticator.
All API entry points supporting a third-party encrypting key are suffixed with WithKey.
Example of routines for delegated protection:
C/C++/Objective C: DPSDK_GenerateSignatureWithKey
Swift: generateSignature
Java: generateSignatureWithKey
Password protection
With Digipass password protection, the usage of the application is protected via a password. This is required for every OTP and signature generation, and for changing the password. The user chooses the password in the course of the activation process and it is part of the calculation of the dynamic vector encryption key. This key is derived from the password provided by the user and from the Digipass serial number according to the following algorithm:
Key = PBKDF2 (PRF, PIN||Serial Number||Device Data, salt, c, sekLen)
The PBKDF2 parameters must be:
PRF: SHA-256
PIN||Serial number||Device data: Concatenation of the user’s PIN, the Digipass serial number and the device-specific data
Salt: Fixed data
C: Configurable number of iterations
sekLen: Key length – 32 bytes
Activation with password protection (overview)
In Activation with password protection (overview), the dynamic vector is protected by a password which the Digipass owner provides. The control of the password fully relies on the Digipass SDK. Only the owner of the password will be able to use the Digipass authenticator.
Once a user password protects the secret in the dynamic vector, any operation involving the secret will require the validation of the user password. This password validation is done by the Digipass SDK according to the password security level defined in the static vector.
The user password can be entered as a string or as a byte array. When entered as a byte array, the password can be reset to avoid security issues.
Weak password control
Weak PIN rules have been updated in Mobile Security Suite 4.21.2
If weak password control is configured for the Digipass authenticator, the detection rules for weak passwords are:
The difference between consecutive digits of the password must vary.
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.)
When the password is changed, the new password must be different from the old password.
Weak password control is used during the activation process and password change.
Weak password control with numeric passwords | ||
Password | Steps suite | Control result |
---|---|---|
123456 | 1 1 1 1 1 | FAIL |
111111 | 0 0 0 0 0 | FAIL |
678901 | 1 1 1 -9 1 | SUCCESS |
02468 | 2 2 2 2 2 | FAIL |
876543 | -1 -1 -1 -1 -1 | FAIL |
123467 | 1 1 1 2 1 | SUCCESS |
415263 | -3 4 -3 4-3 | SUCCESS |
Weak password control with alphanumeric passwords | |||
Password | Decimal Value | Steps suite | Control result |
---|---|---|---|
ABCDEF | 65,66,67,68,69,70 | 1 1 1 1 1 | FAIL |
tsrqpo | 116, 115, 114, 113, 112, 111 | -1 -1 -1 -1 -1 | FAIL |
Weak password control with ATM rule | |
Password | Control result |
---|---|
000005 | FAIL |
200000 | FAIL |
007000 | SUCCESS |
Password security level
The password security level determines how the Digipass SDK validates the password. The Digipass SDK supports the following security levels for password validation:
No password check. Each password is used as-is to decrypt the Digipass secret. Only the password provided during the Digipass activation to encrypt the Digipass secret will generate a correct OTP or signature. Other passwords will generate invalid responses. This 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 Digipass lifecycle, 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 Digipass secret will not be correct and the incorrect secret will be encrypted with the new password. The result is a definitive Digipass secret corruption. The Digipass 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 Digipass lifecycle, 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 Digipass keys.
Password penalty
The password fatal counter is decremented every time a wrong password is entered, and reset on correct password submission. When the counter is consumed, the Digipass SDK applies a penalty.
If the password security level is set to checksum or hash, wrong passwords matching the security level will also reset the counter. Setting the fatal counter value to 3 triggers the penalty when the user attempts a fourth time to enter the wrong password.
Reset key penalty
The reset-key penalty consists in resetting the Digipass secret in the dynamic vector. The secret is deleted and the Digipass instance needs to be reactivated. The event-counters are not reset. The Digipass status is set to locked.
Generate invalid OTP penalty
The generate–invalid-OTP penalty consists in generating an OTP, regardless whether the entered password is correct or not. Only the right password, that is, the one used during the activation, will generate a correct OTP.
With this penalty, if the submitted password matches the password security level but is not the correct password, the following will happen:
On OTP/signature generation, the dynamic vector-encrypting key calculated from the wrong password will be incorrect, and therefore the decrypted Digipass key will be incorrect as well. As a result, the generated OTP/signature will be invalid. Even if the dynamic vector-encrypting key is incorrect, the original Digipass key is not changed as it is not re-encrypted. If a valid password is entered, the Digipass SDK resets the password fatal counter in the dynamic vector to its initial value (set in the static vector). The application status is reset from generate invalid OTP to activated.
On password change, the dynamic vector-encrypting key calculated from the wrong password will be incorrect, and the decrypted Digipass key will be incorrect as well. The dynamic vector-encrypting key calculated from the new password will encrypt a wrong Digipass key that is not correct, which will compromise the key.
In this case, the Digipass key is lost and the application needs to be re-activated.
Digipass scenarios for managing incorrect passwords
See Password error management during response generation (overview) for different scenarios that may occur if the user enters a wrong password.
Password error management during response generation (overview)
The Digipass password can be validated without response generation by calling one of the following functions:
validatePassword for the Java API
validatePassword for the Swift API
DPSDK_ValidatePassword for the C API