Security key management#
Configuring security keys#
Blitz Identity Provider allows you to use security keys (WebAuthn, Passkey, FIDO2, U2F) for identification and authentication. The WebAuthn’ specification is used to interact with security keys.
The following key types are supported:
External keys - are hardware devices in the form of USB keys or key fobs connected to PCs, tablets and phones via USB port, Bluetooth or NFC. The keys do not require drivers or plug-ins to be installed on the device - interaction with the keys is performed through the built-in capabilities of browsers.
Built-in keys - Authentication mechanisms built into the device and operating system that support WebAuthn:
Windows Hello - you can sign in using Windows PIN, fingerprint verification or facial recognition;
Touch ID or password on your MacBook;
Touch ID or Face ID on an iOS cell phone or fingerprint verification or facial recognition in Android.
Security keys are configured on the tab Security Keys of the section Authentication of the admin console.
The following settings are available:
Authentication system name – it is necessary to set the name of the authentication system or application name suitable for displaying to users.
Authentication system domain – must match the domain used by the authentication system or be a superior domain. Security keys will be issued to this domain.
Signature algorithms – it is recommended to specify ES256 and RS256 algorithms as a minimum to work with Passkey, Windows Hello and most common hardware FIDO2 and U2F security keys.
Limit Allowed Authentication Means – If “Not Selected” is selected, authentication means are not limited. If you select “Portable”, only hardware security keys (USB, Bluetooth, or NFC) will work. If you select “Built-in Platform”, only security keys built into devices (Windows Hello, Touch ID on MacBooks, Touch ID and Face ID on cell phones, and using your phone as a Bluetooth-enabled authentication tool) will work).
Key Verification Mode – When “Browser detection” is selected, the user will be shown all security keys available on their device for the authentication system domain. When “Server Discovery” is selected, the user will be prompted for a login, and then only those keys that are available on the device and linked to the user’s account on the server will be shown.
Wait Time – Specifies the time in milliseconds that the authentication system will wait for the browser to respond to a request to access the security key.
Displayed user name – specifies the wildcard pattern according to which the name of the memorized user is displayed on the Security Key login page in the authentication system (relevant when using the “Server detection” mode).
Displayed Account ID – Specifies a wildcard string pattern that displays the name of the security key to the user on the device.
Normal Authentication Counter Shift – a setting that specifies that the authentication server will compare the authentication count on the device with the authentication count of the same key on the server and, if it differs by more than the number specified in the counter, will disallow the use of the security key (key cloning protection).
Blitz Identity Provider authentication server is configured as standard to trust all known root and intermediate certificates of the TPM modules, FIDO, as well as the current Apple and Google certificates required to verify the signature of FIDO2 and U2F attestation objects. If necessary, скорректируйте allowed attestation certificates.
The use of security keys on the first and second factor is described in the following sections.
Logging in via WebAuthn, Passkey, FIDO2#
It is possible to use security keys (WebAuthn, Passkey, FIDO2) to log in to Blitz Identity Provider.
To configure the login using security keys, you need to set the following settings on the tab First factor:
Allowed attestation modes – using only
FULL
andFULL_NO_ROOT
modes will increase security, but will not allow to use some keys for login, as well as Windows PIN code, because when registering such keys the attestation object comes without chipset or key manufacturer’s signature or using a self-signed key. The use ofSELF
mode allows an attacker to implement a man-in-the-middle attack to spoof the key at the time of registration, in case the user’s device is controlled by the attacker.Show method only to users who have bound a security key to the account – If Blitz Identity Provider has already identified the user, it already knows if security keys are configured for the user’s account. If security keys are not configured, you can configure that the user is not shown the login method using the security key.
Equate the use of this method to the use of the first and second factor – if the option is enabled, logging in by security key will mean that the user has passed two-factor authentication.
Правила соответствия – при входе по ключу безопасности пользователя просят ввести логин. Настройка правил соответствия позволяет указать правила поиска соответствия учетной записи введенному логину. Для найденной учетной записи будет запрошена проверка входа по ключу безопасности. Для создания правила используется строка подстановки:
${login}
– это строка, введенная пользователем в поле «логин». В результате, например, правилоemail=${login}
означает, что строка, введенная пользователем, будет сравниваться с атрибутомemail
в хранилище данных.
Attribute store selection rules – as in the case of sign in by login and password, by default the user search for authentication is performed in all active stores. In the Attribute store selection rules block you can configure rules, when executed, the user will be searched in a certain store.
Login confirmation with WebAuthn, Passkey, FIDO2, U2F#
It is possible to use security keys (WebAuthn, Passkey, FIDO2, U2F) to log in to Blitz Identity Provider.
To configure login confirmation using security keys, you need to set the following settings on the tab Second factor:
Allowed attestation modes – using only
FULL
andFULL_NO_ROOT
modes will increase security, but will not allow to use some keys for login, as well as Windows PIN code, because when registering such keys the attestation object comes without chipset or key manufacturer’s signature or using a self-signed key. The use ofSELF
mode allows an attacker to implement a man-in-the-middle attack to spoof the key at the time of registration, in case the user’s device is controlled by the attacker.Show method only to users who have bound a security key to the account - If security keys are not configured, you can configure that the security key login confirmation method is not shown to the user.