FIDO2 Deployment in the Enterprise
Learn more about the product, pricing and features of AuthN by IDEE.
Request a free demo today!
What is the FIDO2 Standard and Why Should Enterprise Care?
FIDO Authentication, developed by the FIDO Alliance, is an authentication standard based on public key cryptography, and aims to reduce the world’s reliance on passwords to better secure the web.
FIDO2 is a standard that many vendors and organization seek to adhere to achieve the highest possible level of security in the case of authentication.
In this post we are going to explore the advice emerging from FIDO Alliance, created to support the deployment of the FIDO2 standard in the enterprise. The advice is centred on two subsets of the standard - WebAuthn (passkeys) and the FIDO2 security keys). We will discuss the recommendations and how to execute it along with the challenges it poses.
What is a Passkey?
First up. What is a passkey? A passkey (or WebAuthN) is a subset of the FIDO2 standard that relies on the in-built hardware cryptographic chip on a device without the need of an external device. It has been adopted as a way of authenticating without passwords and is supported by platform providers such as Google, Microsoft, and Apple.
It works by creating two keys: one public and one private. The private key remains locked to a device and the public key is stored on the identity or platform provider’s server. When a user is trying to login and access their account, the private key is used to digitally sign the login request, the public key is used to verify the digitally signed login request to grant access. This means the public keys are useless without the device-specific private key. When the user unlocks their device to login, it demonstrates that the user is in control of the device, the digital signature which is signed by the private key that exists only on that device demonstrates possession of the private key and device. Unlocking the device using biometric or PIN is the first factor, possession and control of the private key/device is the second factor. This is how MFA (Multi Factor Authentication) is achieved. Sounds good so far.
FIDO2 Strategy: A Summary
There is a lot of technical detail. We have gone through and done the heavy lifting and thought we’d provide an overview of the key points in an easily digestible list.
Strategy for Deployment
Here is a summary of how the deployment should take place according to the advice from FIDO.
1. Enterprises should support passkey via Identity Provider (IdP), so it propagates across the enterprise applications.
2. If a single-sign-on (SSO) mechanism is used to federate multiple applications and services, adding passkey support to the Identity Provider (IdP) can propagate support for passkeys to numerous federated applications, creating a rich ecosystem of services supporting passkeys with engineering efforts focused on the SSO IdP.
3. Enterprises should consider whether users who move between several shared devices should synchronize passkeys across all the shared devices, use hardware keys, or use the hybrid flow to best support their work style.
- When users operate on shared devices using a single account (or profile), passkeys registered to the platform or credential managers are not a good fit. Device-bound passkeys (hardware security key) are recommended for this scenario.
- If the user carries a mobile device, consider registering a passkey on the device and using the cross-device authentication flow to authenticate users.
4. Moderate assurance organizations can support all their users by implementing synced passkeys for their standard users to replace passwords and then use hardware security keys for highly privileged users and their access to resources that require the highest level of assurance.
- Implementing both types of passkeys in the same authentication domain does however create an additional challenge that will require organizations to take additional steps to ensure that the correct type of passkey is used when accessing resources. For example, ensuring that a highly privileged user is using a hardware security keys and not a synced passkey when accessing a resource that requires a high level of assurance.
- In federated authentication environments, this may be communicated using standards such as OpenID Connect.
5. Synced passkeys would not be a good solution for those organizations that require an elevated level of assurance, and they should look to hardware security keys to support those use cases.
6. Organizations can allow the registration of only a specific set of authenticators.
Strategy for Managing Recovery:
1. The FIDO Alliance recommends the following two-step strategy for managing account recovery:
- Multiple authenticators per account (reduction of account-recovery needs)
- Re-run identity proofing /user onboarding mechanisms (actual execution of account recovery)
2. If using hardware security keys, organizations should provide two per user to allow for a backup credential. If a user loses their hardware key, they must have a backup or perform account recovery for all credentials stored on the device.
3. As long as a password remains active on the user account, the user can recover from credential loss following the self-provisioning described above. This step is only required if the user is unable to restore their credentials from their passkey provider.
The Challenges with the FIOD2 Approach
Any steps taken to make organizations more secure, less reliant on passwords, (which, let’s face it are obsolete), or to introduce industry standards is certainly a move in the right direction. However, there are challenges and still vulnerabilities in the FIDO2 approach. Here is our take.
Synced Passkeys Create a Dependency
Synced passkeys create a dependency on the passkey platform provider and their synchronization fabric. Each provider implements their own synchronization fabric, which includes their own security controls and mechanisms to protect credentials from being misused.
Passkeys May Be Shared with Other Users
Passkeys may be shared with other users if they are not hardware bound. This means anyone on any device can use the passkey to login to the account. This could lead to account takeover, which is one of the outcomes this standard is attempting to protect against.
Organizations Cannot Keep Track of Devices And/Or Credentials
There are currently no standards or systems that allow organizations to keep track of what devices these credentials have been created on or and stored upon. Nor are there mechanisms to identify when the credential has been shared with another person.
The consequence is that organization depends on the platform such as Google and Apple for the security of their assets. This is a big threat to the overall security of the organization because employees can sync the passkeys to personal devices and may even sell them to hackers such as Lapsus$ in return for a share of the ransom. Furthermore, governments have the power to request the platforms to handover all the passkeys which they could then use to access people's accounts.
Fallback to Password
Multiple authenticators per account cost money and as a result most organizations cannot afford it. Also. there is no guarantee that two authenticators cannot be stolen or lost at the same time.
This leaves most organization to rely on passwords as fallback method. This means FIDO2 is as secure as the fallback recovery method (in this case password). This opens the door for credential phishing and password-based attacks.
Synced passkeys do not implement attestation, which means they are not an appropriate solution for scenarios with highly privileged users that require higher levels of assurance or for organizations that want to implement Enterprise Attestation.
In conclusion we fully applaud the efforts to makes everything more secure. We agree that passwords are redundant, and industry must find new ways of authenticating users privately and securely.
Standards like FIDO2 are extremely helpful in this endeavour and help to bring continuity and assurances across different solutions. However, it is important that it is never seen as a box ticked and a 100% guaranteed fail-safe. This method is secure but only really to a certain level. Passkeys are only as strong as the password used to protect a user’s Google, Microsoft, or Apple account. This makes synced passkeys vulnerable to password related attacks.
Phish resistant is not the same as phish-proof. If organizations want to guarantee phish-proof authentication, they should be looking towards solutions like AuthN by IDEE.
To find out more, book a demo with us. We’d love to show you around.