In March 2019, WebAuthn was declared a W3C web standard. At the time, WebAuthn received its own fair share of hype. It promised to smooth the user experience of biometrics by making user enrollment more intuitive and supporting cross-device and cross-platform biometrics. However, four years later, it’s fair to say that WebAuthn’s adoption has been minimal, particularly in B2C use cases where there’s a higher emphasis on user experience.
A major reason for WebAuthn’s limited adoption is that the technology has been sidelined into a secondary authentication method rather than being offered as a true primary method to users signing up for or logging into an account. There have been two main problems with WebAuthn as a primary authentication factor:
User experience of WebAuthn as a primary factor – either for “passwordless” or “usernameless” scenarios – has been pretty rough. The WebAuthn W3C group has put together a document that goes into far more detail. One of the items out of that discussion was a standards change that was merged in a few months ago. Now it’s up to browser vendors to implement that change over the coming months and years.
Lock-out risk: The second problem with WebAuthn is that device-based authentication has been historically risky for consumer users long-term. It’s unreasonable to expect an individual to have access to their phone, YubiKey, or laptop over a period of years. In the B2B space, this isn’t as big of a deal. Getting an IT admin that works for your company to reset your access and issue a new credential is not a complex problem. However, this is a major hurdle is that devices get lost or stolen, and then the service operator needs to build out an alternative recovery method that needs to be as secure as WebAuthn (ideally, without infringing on the user’s privacy, as regulated by Know Your Customer (KYC) mandates).
While passkeys offer a more secure way to authenticate users, it is important to be aware of their limitations and potential drawbacks. Passkeys are a part of the FIDO implementation where a pair of public and private keys are used to authenticate a user. In this scenario, the private key is stored at the user’s end device from which the challenge response (signing the challenge with private key) is initiated. The public keys are stored at the relying party -aka authentication server.
Here are some of the disadvantages when using passkeys:
1) Risk of Loss or Theft:
If a passkey falls into the wrong hands, it can potentially grant unauthorized access to the protected system or device.
2) Limited Applications:
Passkeys are typically used for specific devices, systems, or services. They may not be compatible with all platforms or applications, which can be inconvenient for users.
3) Potential Problem With Cryptography:
Cryptography largely depends on large prime numbers, making it quite complex. A successful server breach may give criminals access to the public keys. With evolving quantum computing, corresponding private keys can be cracked within a given but limited time. Not to inject fear, but a healthy caution on the roadmap.
4) Non-Obvious Interaction:
After setting up passkeys, it’s non-obvious to consumers how to interact with them. This can lead to confusion and frustration to the users. Can there exists a login process that is intuitive and almost same as the current user-id/password “experience” and yet be anti-phish anti-spoof? The answer is “yes” and take a look at the the iLogsafe video to see exactly what we are talking about here.
In this scenario, there are trade-offs from a risk perspective. First, it is always a possibility that an attacker can replace the public keys at the authentication server rather than going at use’s end devices as we have elaborated in our earlier article here. As such it is indeed true that public keys really carry value at the authentication server rather than simply brushing under the rug that with a statement like: “Oh, they are just public keys not much harm can be done with public-private key pair-based authentication”.
Secondly, in practice the signature signed by a private key can be verified only with a corresponding public key in the asymmetric cryptography, the strength/unique property advantage can also be viewed as a drawback. Every device from which the user intends to authenticate needs that private key to sign a response to a challenge from the authentication server. This can be done in two ways –
1. Replicate Passkeys on _all_ end devices
2. Introduce another channel to interact with a device holding Passkeys (pvt keys in essence)
Passkey introduces the replication of the private keys across the devices. This also alludes to the familiar “password-sync” problem across systems
- Any new site that registered a new public key needs to be synced across all the devices and replicated – aren’t we back to square one? Password synchronization is well understood and the issues around them aren’t simple to solve.
- Increasing the attack surface with the replication of passkey (chains) both either in cloud or at the forsaken end devices
In contrast to this scenario of a single private/public key replication, one can easily generate Bearer-aware codes specific to the devices from which the user logs-in without having to replicate the secret across the devices as we witness here
In this case an agent on each device holds no real secret, but enables to generate unique anti-theft, anti-spoof login codes by the single app on the mobile that holds the keys. This way, while having flexibility to login from any device with a one-time pairing with the mobile app to establish the trust, without having to replicate the actual secret keys across all the devices from which the user intends to login. As such the bearer-aware authentication app generates codes specific to that device that the user initiates and intends to log in. In this case only a single backup (at no cost) can be kept by the user in case of lost or stolen devices. There is no account recovery process at the authentication server to abuse, by the hackers.
| Attribute/Attack Surface | Bearer-aware codes (iLogSafe) | Passkey (Pub/Pvt Key pairs) |
| Replication of secrets | Only on backup devicesAttack surface is restricted | On multiple devices Attack surface increases proportionally |
| Device specific login | Agent holds no secrets, but facilitates to generate device specific login codes with local public/pvt key one time registration | Nope ; The same key pair (pub,pvt) is needed at the time of registration; As such the pvt key chain is replicated or use centralized cloud hosted secrets |
| User experience | Same ; minor delta steps to generate device specific codes | Entirely new and non-intuitive experience as we have seen with webauthn |
| Backward compatible with Password, MFA? | Yes, just an add-on to the existing infrastructure but you get anti-[phish, spoof, bypass] capabilities | No ; get rid of entire-legacy system to pave way for anti-phish capabilities |
Thus bearer-aware anti-[phish, spoof, by-pass] retains the same user login experience, but at the same time without necessarily uprooting any existing authentication mechanisms.
Watch Anti-[Theft, Replay, Bypass], No-Passwords, iLogSafe Security
Sign up for a free trial to see the anti-[theft, spoof, bypass] security of BOTP /iLogSafe today here.
