FIDO2 Security Keys PIN Protection: When and Why PIN Is Asked?

Token2 RD
4 min readMay 4, 2024

--

We’ve been receiving inquiries from our users regarding when a FIDO2 security key requires a PIN for protection. Some services consistently prompt for a PIN, while others never do, and some do so intermittently. In this article, we’ll delve into this matter.

When utilizing FIDO2 Security keys, user verification serves as a fundamental aspect of safeguarding sensitive data and thwarting unauthorized access.

The decision whether to authenticate with a security key with or without a PIN rests with each website or authentication service. This can be determined globally for all actions or on a per-operation basis. The authentication service accomplishes this by setting the userVerification property to one of three options: required, preferred, or discouraged.

Each option carries its own implications for security and user experience:

  1. Discouraged: Opting for discouraged verification means users won’t be prompted to enter their PIN during the authentication process. This option is typically chosen when additional protections, such as a password, are in place.
  2. Preferred: Choosing preferred user verification prompts for a PIN only if one is set. This strikes a balance between security and user experience and is often combined with another factor, like a password.
  3. Required PIN: Opting for a required PIN setting mandates users to enter their PIN during every authentication attempt. If no PIN is set, the service will require the user to set one and will not allow registration without it.

How to Check This Behavior?

Of course, you can test this with various systems and their authentication settings. For instance, Entra ID Passwordless mandates user verification, as the FIDO2 key is the only authentication method, hence a PIN is always required to make the authentication multifactor. In contrast, GoDaddy doesn’t enforce this; because a password is necessary before using the security key. However, using our FIDO2 Demo page simplifies this process.

We’ve included a selector on our FIDO2 Web Demo site that enables users to define the user verification behavior.

While these settings are typically fixed on the server-side and not selectable by end-users on production servers, we’ve made them available for our demo purposes.

To better comprehend the three modes, let’s begin with a fresh, factory-reset security key without any PIN set. On the FIDO2 Demo tool, selecting “PIN: never” or “PIN: if set” allows our security key without a PIN to complete the test without any additional actions required.

However, choosing the “PIN: always” option changes the user verification mode to strictly require a PIN. In this case, the system will refuse to proceed without a PIN, prompting the user to set one (note that not all browsers may display the set PIN dialog; in some cases, alternative tools may be necessary).

If you’re using a security key with a PIN already set, selecting the “PIN: never” option ensures the PIN will never be requested. For the other two settings, the PIN will be prompted.

Controlling This Behavior

While we typically inform users that the decision to request a PIN is made by the authentication system, for the latest generation of FIDO security keys running FIDO2.1 (not FIDO2.1PRE), there’s a setting that allows users to override this.

In addition to the authentication service’s settings, FIDO2.1 keys feature a setting called always_uv (interpreted as “Always require user verification”) on the key itself. This setting enforces PIN requests in all cases, irrespective of whether the RP requests it or not, empowering users to enhance their security independently of service settings.

Platform authenticators and other authenticators with the always_uv feature enabled will always perform user verification, even if the Relying Party sets user verification to Discouraged in a WebAuthn request. While this isn’t mandated by the FIDO standard, some users or organizations may desire the PIN to be always requested, and this feature accommodates such preferences.

Valuable to understand: enforcing user verification adds an additional authentication factor to the flow where security keys are used in combination with passwords. For instance, with the always_uv setting enabled, the authentication process expands to three steps, enhancing security:

  • Entering Password: Users start by entering their password, serving as the first authentication factor.
  • Plugging in and Pressing Button/Sensor on the Security Key: Users interact with the security key by plugging it in and pressing a button or sensor for the second-factor authentication.
  • Entering PIN: With the always_uv setting enabled, users are prompted to enter their PIN, adding another layer of verification to the authentication flow.

How to Set This Setting?

To enforce user verification to always be requested, you can use our command-line management tool for FIDO2 keys, fido2-manage.exe, with the -uvs (or -uvd) option, available starting v0.2.2. Before issuing the command below, ensure you have a PIN set on your security key.

fido2-manage-ui.exe -uvs -device 1

(-uvs stands for user verification set, will set always_uv flag to true). If this parameter hasn't been set, it will prompt for the PIN. To revert this back to disabled mode, use the command below:

fido2-manage-ui.exe -uvd -device 1

(-uvd stands for user verification disabled, will set always_uv flag to false ). If this parameter has been set as true, it will prompt for the PIN to set it to false.

Please note that this feature is exclusive to keys running the latest FIDO firmware, namely FIDO2.1 (not FIDO2.0 or FIDO2.1PRE). In compliance with FIDO’s specification, this is disabled by default on our keys, and after a reset, it will be set as disabled as well.

Please note that the term “PIN” is used here as a common term for simplicity; for biometric security keys, the PIN is replaced by a fingerprint scan. User verification applies to biometric security keys as well.

--

--

Token2 RD
Token2 RD

No responses yet