A Yubico FAQ about passkeys
yubico.com
yubico.com
Tying login credentials to a hardware device that can easily be lost or stolen, and that (at least from my understanding) are hard to transfer to new devices seems like a risk I'm unwilling to take. And a step back.
I'm not adverse to replacing passwords with public/private key cryptography, but I need to be in control of it (not some multinational org) and I don't want it tied to a single hardware device.
As for theft, if you’re using your yubikey as a 2nd factor then they still can’t log in because they don’t know your password. If you’re using your yubikey as both factors then it either has a PIN or biometrics, so the thief can’t log in.
My main use for my yubikey is for SSH. I have PIN-protected SSH with a private key that can’t be exfiltrated
Appears that while they couldn't fix it, they have gone ahead with a workaround and made multi-device 2FA support a feature in a potential auth replacement system.
Must have been a particularly frequent and loud complaint.
One of my keys failed spontaneously after a just few weeks in my pocket, on a ring with my other keys.
I decided to stop using yubikeys. A password manager has worked very well for me ever since.
I use a password manager, but my Yubikey has all my 2FA. Including TOTP.
How does this work? Do you have to physically retrieve both any time you sign up with a new service?
If that's how it works, it sounds like a choice between two bad options: either having both of them handy at the same time, hurting redundancy, or registering them at separate times, hoping you remember to do both. Is that the case?
You will have to retrieve your key when you sign to a new service. at this point you risk losing both.
or are you saying you cloned the private keys and know how to correctly advance the counters when you need the backup?
Since I use my Yubikey for SSH, I’m frequently adding both Yubikeys as authorized keys on machines. But I keep an authorized_keys file with both public keys so I don’t need to physically grab my backup
This way, you don't need to have two yubikeys on hand and register them both on every new site. But in case you lose, it's not impossible to create a new one. Yet, obtaining the key from the hardware token shouldn't be any more possible than with the current system.
Most people will never understand this subject, and the fact that they don’t need to is a good thing. If you want a hobby, great, you can go figure out how to do that. The default needs to be safety.
But like I said in the comment below, I suspect these vendors are only here for vendor lock-in and targeted advertising. And the websites enabling webauthn are likely to require you to use a vendors app/service. Like banking sites today not allowing me to utilise keepassxc totp functionality trying to force me to download their app or SMS.
Of course, multi-device passkeys will not work for high assurance situations, as TFA calls out, but that's not likely the case for any of the services you currently use a password manager for anyway.
As it stands today, using passkeys with a software implementation, barring implementation bugs, is no less safe from credential loss than passwords in a password manager.
While your comment is fair, and I know you were just providing info, from where I sit, these are the sort of entities I never, ever involve in any form of private work, security, or communication.
The article specifically states (about passkeys as opposed to Yubikeys):
> They’re different because Platform created passkeys will be copyable by default using the credentials for the underlying cloud account (plus maybe an additional password manager sync passphrase), whereas passkeys in YubiKeys are bound to the YubiKey’s physical hardware where they can’t be copied.
That brings its own challenges of course (e.g. you have to trust the Cloud syncing and E2EE by the vendors).
The first introduces risks with damaged or stolen hardware, not to mention migration.
The second introduces lack of control and enables these companies to track you. It's not lost on me that nearly all the companies offering authenticator apps are basically advertising companies: Google, Microsoft, Apple. They're getting in at the start for a reason
Your password manger could implement passkey support. And I suspect that 1password will do that soon with their recent acquisition.
The real benefit to passkeys is that password isn't sent over the wire, only the proof that you have the secret. Similar to SSH keys. This prevents a whole range of attacks.
But from my reading, and I believe the way this will be implemented but services, I doubt very much you'll be about to do this. Certainly at the moment it looks like vendor lock-in to me. Vendor lock-in with a heavy dose of targeted advertising.
Also, how is Microsoft not an enterprise security company? Their revenue from security products is probably 100x that from advertising.
Microsoft might be an enterprise security company. But they are clearly all about tracking and targeting their users too. The two things are not mutually exclusive.
Re: Microsoft, I suppose there’s no harm in being maximally suspicious. But I have some knowledge of their systems and Google’s and Microsoft does not have , for instance, a single user profile that joins interests and infers demographic data like Google does. I expect the same is true for Apple.
I've no internal knowledge of MS systems but the fact that they make it hard to use their operating system without an online account and you can't opt out of all telemetry and the fact it's default opt-in for all telemetry leads me to be extremely suspicious of them. I'm not saying they're any worse than Google or Apple.
See for instance: https://support.apple.com/guide/security/secure-keychain-syn...
If one of these companies locks you out of your account for any reason, you don’t lose access to the keys. They are not removed from your devices. You do lose the service that moves them between devices.
Anyway, I appreciate you sharing your perspective and I admire your commitment to only use fully open services. Just saying the closed ones may not be as malicious or a usable as you think.
Passkeys have a lot of advantages, but the current plans for implementation are rather limited. If you're interested in passkeys that you can actually control, please check Bulwark Passkey out!
Password safe runs on multiple operating systems. I sync my file to cloud storage so it's up to date on all my devices
I have a backup key in a drawer and one on me at all times.
I really need to buy a few more backup keys.
It's not a perfect set up but it works for me.
I did this recently and the experience has been surprisingly way easier and better than I could have imagined.
Owner of a Pixel that just died in my hands. Had I not been with company that day, I would have been in a real situation.
Edit: also, if I keep it on the phone, will Apple/Google deign grant me access to export my secrets on demand or will they deem I cannot be trusted with such power?
_Breaking in_ is very hard since the security model for phones is very high, especially in cases of Pixels and iPhones. Even if a pin is used, the security chip makes it very hard to break in. If you mean also in case of losing it: Not as a small device that has much more higher chances of being lost.
> Edit: also, if I keep it on the phone, will Apple/Google deign grant me access to export my secrets on demand or will they deem I cannot be trusted with such power?
Don't know about that, since passkeys are still pretty new, but probably it will be an option. Does a yubikey allows you to export secrets?
Edit: typo
No, that would defeat the purpose. If you want exportable secrets just use a thumb drive.
My question would be who is in control of the backups? The same vendors who want to lock you into their ecosystem?
Not the same as a small key that can be stolen.
> My question would be who is in control of the backups? The same vendors who want to lock you into their ecosystem?
You, as it's encrypted (in case of apple, not sure about Google). Backup is up to you, you can also backup to other services such as nextcloud.
There seems to be a API already for a browser to delegate passkey storage to a Yubikey, can’t a password manager do the same thing?
Password manager's job should not be to scrape pages for login fields. That still could be a separate plugin (if browser would not do job good enough), but password manager should really get credentials name, some metadata, notes and password to store, nothing more
A random password stored in a password manager is literally what a passkey is. Several password managers have announced support for storing passkeys just like your passwords.
This is not quite true; a passkey is still somewhat more secure than a password in this scenario.
With passwords, the password itself is sent to the website and a hashed version is stored in their database. If someone can intercept your connection to the site (MitM) or can access their database (hacker), they might be able to get your password and log in as you, especially if the website doesn't implement their hashing very well.
These attack vectors don't apply to passkeys, even generated and synced by a software password manager: the private key never leaves your computer, only the corresponding pubic key. The website generates a unique challenge on each login that can only be solved by your private key, so intercepting a particular challenge or stealing the public key from the website database doesn't let anyone log in as you later.
https://github.com/keepassxreboot/keepassxc/issues/8214
It appears that we are still in the "walled garden bullshit" phase, so I'll pass for now.
It's not really hard. They're quite flexible. You can't read the key from them, but you can write to them. You can generate the key outside, write it, save the backup somewhere you trust to be safe according to your threat model, and that's it. If you lose the device, buy a new one, write the key from the backup. The backup can also be used directly if you can't buy a new device for whatever reason.
At least, this is how it works when used as an OpenPGP smartcard.
For me, the main thing is that using the keys by default make my accounts more secure and I would only use the phishable methods in case of emergency (if my house goes up in flames with my keys, computer, mobile, etc). One important thing for me was to remove my mobile number for SMS OTP or password reset, as sim cloning is a posibility.
And a password manager is still indispensable as most sites don't accept hardware keys at all.
If it was "here is your private key, you can use it in sofware or you can load it on a key and just use" I'd be much calmer about it but the whole push "your authentication and sometimes whole identity is inseparably tied to your device" is frankly scary and disgusting.
Meanwhile, my phone is always near and bitwarden just works.
I personally would love to see it implemented, so it can be used for logging in to the service that provides a WebAuthn sync fabric.
Unless you are talking about something entirely different that scenario isn't possible.
One place I'm kind of sorry hasn't been on the forefront of adoption though and gets into gear soon is web UIs, which often control some pretty important stuff. We run things like OPNsense for firewall/gateway needs, TrueNAS, various controllers, hardware that these days has a web UI etc. With "internal" applications it's already a lot more acceptable to slap heavier access requirements on them, only exposing them via VPN, but it'd be nice to be able to require hardware bound passkeys (to use Yubico's terminology) for web auth (recovery can be done via console if ever required).
I think exporting passkeys could be useful.
I wonder what phishing attempts will look like.
0: https://i1.wp.com/9to5google.com/wp-content/uploads/sites/4/...
Plugging a token into a shared system is superior to passwords as well. Easy, somewhat safer if the system is compromised vs any given password (since an attacker would only be able to perform an online hot attack, and only on things the user was also doing assuming touch is required), much safer and easier compared to a password manager. Externalizing authentication on a shared system into something owned by the user is a pure win IMO for those who need to use them, and if anything is a particular win in that case compared to those who get to use only their own computers.
>Or if you lose access to your devices?
There is no one answer to this and I'm sure UX will evolve over time. As I said, in many cases there is a natural fallback in the form of local access console, same as if somehow all SSH keys or the like were lost. Ideally in general everyone would have multiple tokens, with at least one serving as a backup. Alternatively or in addition, good old backup codes (printed keys, either whole or n-of-m splits) on paper are a reasonable choice in some cases IMO. Some places that have a personal connection may simply have an IRL fallback, ie., your employer would just have you go to IT, or your bank might have you go into a branch in person with ID for a reset. In the future, there could be optional hardware solutions that allowed backing up exclusively to another key. I don't see the problem though as much different, than having hundreds/thousands of passwords to deal with.
>I wonder what phishing attempts will look like.
Pure remote "phishing" as it currently exists just isn't going to be possible with hardware based keys. But online hot attacks still will be, so I'd expect that will be that path taken (though it'll be harder). Stuff like getting people to run programs or waiting for them to access something sensitive on a rooted system such that they do a completely legitimate authentication flow but then additional actions are performed using it. But that's far more limited a threat surface than right now, and also will have more tractable technical counters. Still an improvement.
I guess for a while the other "phishing" that might linger will simply be trying to use the inevitable legacy workarounds that you yourself asked about. Backup codes could certainly be phished in principle, social engineering tech support that "so and so lost access to their devices!", etc. But I think that will fade in effectiveness as time goes on, so might as well get to it. At the end of the day, symmetric shared auth is just insanity and asymmetric is simply fundamentally superior.
Who has managed to do this successfully and without losing their minds?
I hate passwords and would love to complement them with better security factors than my phone alone or find a way to move away from them entirely, but YubiKeys et al do not seem consumer viable to me. And I've tried.
Do you have a code to enter your building or something?
The exercise and showers maybe, but feeling like you need your yubikey with you literally 24 hours a day certainly is. I use them extensively and with everything properly set up perhaps need it a couple of times a week at best. Having it on a keychain or in a backpack is fine.
Hate to say "you're doing it wrong" but you (or your company) certainly seem to be doing something wrong to have this level of hassle. No-one would use them if they were this much trouble.
I even built a Solo 2 key into my framework laptop:
I wonder if something like this could sell on their third-party extension card store.
I don't really want to bother selling it, but I'll upload it to Printables in case anyone wants it.
Yup I really don't get this. For once we had something that made sense: an actual 2FA which required an actual physical device.
And now with the alliance between Microsoft (which we know can always be trusted), Google an Apple the 2FA not only is becoming "1FA" (because the goal is to use the passkey instead of the password, not in addition to it).
But transforming the 2FA to 1FA is not enough: we cannot let these secure hardware module make live hard for law enforcement (uh, sorry, for bad guys) so instead of having "no device, no login" we get instead "copyable passkey".
"1FA copyable passkey"
What a concept.
Somehow I feel this isn't exactly going forward security wise.
Then people will say: "but it's easy. but it's convenient. And moreover it's pushed by our beloved Microsoft!".
Yup, exactly.
Both Windows Hello and Microsoft Authenticator (in passwordless mode) are brilliant examples of passwordless done in a secure way that is also incredibly user friendly to both use and set up.
One important aspect is that Web Authentication is an abstraction API for talking to an authenticator. The authenticators themselves can have wildly different policy/characteristics.
Apple in particular is pushing exclusively toward the consumer space requirements with their current implementation of Passkeys, solely as a more secure password replacement.
This means that clone ability and sharability are fundamental concepts for them, which currently go against business and regulatory requirements in several spaces. Since mandating creation of hardware-bound credentials goes against consumer usability, there isn't a clear path toward supporting them outside enterprise enablement via MDM.
Android's current plans are to only support hardware-bound credentials for second-factor usage, not for passwordless usage.
Microsoft will likely allow for user choice as to whether a credential is hardware-bound. I'm not aware if they will allow the relying party to dictate a requirement here.
Yubico meanwhile has a FIPS-certified key, and has been pushing toward support at higher assurance levels per NIST 800-63. While additional hardware is annoying for users, to the business it amounts to a per-seat cost to solve a real problem.
> However, unless they pivot their model towards the OEM market and start selling there chips to phone manufacturers, I can't see them ever hitting the mainstream.
They have an interesting model in that, while a business may need a user to have a Yubikey or similar authenticator, there often isn't a requirement that they have one specifically provisioned and shipped by the business. I've seen environments where key fobs are provisioned to users primarily through Amazon.
So I suspect Yubikeys will settle into a business user and prosumer space, but no the chance of widespread consumer adoption was always slim. The broader adoption of WebAuthn gets however, the more opportunities I think Yubico will have to sell into the gaps.
[Disclaimers: WebAuthn WG member, FIDO 2 TWG vice-chair]
Can someone explain what discoverable credentials have to do with a passwordless experience? Accepting a WebAuthn credential in lieu of a password is a policy decision and is every bit as possible with non-discoverable credentials. As I see it, discoverable credentials enable a usernameless experience, which is a rather different phenomenon.
Depends on how much information you want to leak about user accounts.
A non-discoverable credential requires a credential handle value from a previously registered credential to be given in the WebAuthn "get" request. That means you need to understand who the user is to look up the set of possible credential handles to supply.
Credential handles are a vendor-specific format and are not required to be cryptographically random, so this leaks information such as that an account is valid, how many keys they have registered, and potentially which vendor/model keys those are.
The other challenge is somewhat orthogonal to discoverable credentials, and that is authenticator support for user verification. Since the older U2F keys support neither discoverability nor user verification, and since newer discoverable credential usage doesn't make a lot of sense without user verification, the two features sometimes conceptually get bundled together.
Without user verification, your authentication only represents (at most) a possession factor. In several spaces this is considered less secure than a password and insufficient.
I've heard of efforts to support non-discoverable first-factor authentication via an initial username prompt, but I haven't actually interacted with one in production yet.
I believe I have interacted with sites which will do periodic non-discoverable challenges after an initial (password-backed) user login, e.g. step-up a long-term cookie-backed session. These are typically relying on mobile phone/desktop support, and represent it as a faster login option on that device for the future. Since these environments are getting passkeys, I suspect they will eventually migrate over to discoverable credentials with user verification.
Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
An agent that registers non-discoverable credentials as discoverable ones via local storage is an option, although not one that browsers have yet chosen to support.
This however locks you onto a browser (if it doesn't have a cloud sync fabric) or into a particular ecosystem (if that browser has a sync fabric). Authenticators support discoverability because a limitation of only being able to authenticate in a single browser is significant.
Since authenticators tend to either support both discoverability and user verification, or neither discoverability nor user verification, I suspect there won't be business drivers to support such user agent storage/functionality.
Note that the CredProtect extension protects discoverability of a resident credential without user verification, and Chrome requests this extension on sites' behalf by default. This protects against scenarios where a third party who gets physical access to your authenticator (thief, partner, law enforcement, border control) can introspect the websites you have accounts at without your participation.
> Also, how is enrollment of an attested-but-not-present token or a multisig group of tokens or anything that enables off site storage of a token not part of the spec? It even seems like a company like Yubico could hack up a pair of tokens that separate enrollment and authentication without a spec change. Of course, discoverable credentials are a bit of a step backwards in this regard.
There was a serious proposal: https://github.com/Yubico/webauthn-recovery-extension
The challenge is that support for such things (new multisig algorithms, this recovery extension) require active relying party participation, and many would just choose not to take on the extra effort.
So instead we have multi-device credentials, where there is a sync fabric behind the scenes. Nothing would preclude hardware credentials from participating in such a thing, although they would obviously need either radios or software assistance to do so.
To capture the change in physical hardware, a new extension (devicePubKey) is being proposed under Web Authentication. This would have the benefit over the previous recoverability proposal in that sites opt-in to extra responsibility as needed for their business logic, compared to usability being restricted unless sites do extra work.
It might confuse people that passkeys is design as "a password replacement" (https://fidoalliance.org/passkeys) but it also can be a FIDO2 as additional authorization method. Once you setup the FIDO2 PIN for YubiKey, you have to enter the PIN every time at registering your key. Which makes me annoying and reset my YubiKey to delete the PIN.
Although Windows, Android, iOS and macOS all implement the passkey. But Google and Apple account does not support passwordless login. Microsoft still using their own implement of passwordless login. Recently Apple announce that they will support to use hardware key for two-factor authorization. (https://www.apple.com/newsroom/2022/12/apple-advances-user-s...) It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID.
In the specification, it provides multiple algorithm choices for website developers. (https://www.iana.org/assignments/cose/cose.xhtml#algorithms) But Android, iOS and macOS only support ES256. Newer Windows support ES256 and RS256. Older Windows only support RS256. EdDSA is only supported by YubiKey.
Passkeys are used to describe an alternative to passwords, and as such the term is used to indicate particular characteristics for the user (such as being a primary factor and supporting password-manager-style user experience).
FIDO authenticators and the WebAuthn API can be used to support other scenarios, such as second-factor usage. They also may support additional extensions, or support supplying attestations.
But if you wanted to say what a passkey is as a technically defined object, it is a multi-device (backup-capable) WebAuthN credential which is discoverable and supports user verification.
Likewise, there are single-device passkeys, which are non-backup-capable WebAuthN credentials which are discoverable and support user verification. Yubikeys support creating such credentials, and thus support creating single-device passkeys.
> It looks like Apple have no interest at either passwordless login and supporting cross-platform passkey for Apple ID.
Apple is notorious for not talking about future plans; however, all of the companies you mentioned are likely going to implement this technology in an incremental fashion. For example, that Apple is rolling out support for authentication via FIDO security key fobs as an advanced security option does not preclude broader WebAuthn login support for web and native access to all Apple accounts in the future as an alternative. Advanced security modes are just easier, as they are advertised as having significant usability impact.
There are just real issues here left to solve, for example authenticating to an account on an Apple TV unit, where neither USB nor NFC are generally available.
Normal people expect simplicity and consistency and are totally confused.
Most people like when technology is easy to use, but tech people can also appreciate when technology is a well designed complete package that makes it so the most people can benefit from the cool tech improvements. My favorite example here is Signal, which both significantly improved upon the security of previous solutions like PGP encrypted email and was a massive usability improvement such average people could take advantage of the security it offered. As a tech person, I appreciate the latter at least as much if not more than the former. Security keys check the first box, but I'm not sure they've got the usability thing down yet.
...am I not a tech person? Hold on, need to go do some existential musing.
What I would like is a recovery key that I can store in a rarely-accessed safe.
Here's an idea from an old paper of mine: on every sign up, you register not only your primary device, but also a recovery pair made of [hash(recovery_token), encrypt(master_public_key, recovery_token)]. Then you keep your single master_private_key in a safe.
If you ever lose your primary device, you then:
1. Take your master_private_key from the safe (e.g., printed QR code, backup device, passphrase for key derivation, etc).
2. Ask the service for your encrypted recovery_token and decrypt it with your master_private_key.
3. Ask the service to reset your credentials and use the recovery_token as authentication, to be checked against the expected hash.
This way you can create recoverable accounts without carrying your backup key, without downgrading to non-hardware security, without giving personal information like email address for out-of-band resets, and without creating a backup that has to be updated.
As a bonus, you can use hash(master_public_key || service_domain) as username for anonymity without extra storage. And this process also works to recover compromised accounts, something you don't get with two Yubikeys that can remove each other.
Good point, in that they are both based on backup credentials generated on-demand. But the Yubico scheme is a lot more complicated and limited to backup devices (as opposed to passphrase or printed QR code). On the other hand, the signed handover is really cool, and doesn't require the server to store encrypted data like in mine.
> In my opinion, along with pluggable Passkey providers, this is the missing piece for a usable and secure passwordless ecosystem, especially now that iCloud will start supporting security keys.
I agree completely.
To start with, why throw out the password? We have literally spend a decade getting people to use 2FA - and rightfully so. Why would we suddenly voluntarily compromise security and go back to 1FA? Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator. I am quite worried that websites will adopt this form of 1FA as the "new normal", compromising the security of anyone who still wishes to use secure passwords.
Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature, but meanwhile vendors only allow syncing between their own devices. This makes a multi-vendor environment extremely challenging to use, not to mention that switching to another vendor risks losing access to a lot of websites. And that's even ignoring the possibility of a vendor getting mad at you and deciding to nuke your account - and all the passkeys with it. Until there is a proper (open!) standard for exporting and importing passkeys, this is an unacceptable risk to me.
Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction. To me, it looks like Google/Apple are trying to replace "Log in with Google/Apple" with "Log in with Passkeys" to make it seem like it is an open platform, while still locking it down as tightly as possible. Despite being an open standard, the implementations are anything but.
Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop.
I am also seeing a lot of misleading statements surrounding its security. For example, the claims that the keys are stored in a TPM/Secure Enclave. Meanwhile, in practice the TPM is only used for the local encryption of a copy of your passkeys. They also happily live on the cloud because they are being synced, and the vendors seem to be offering ways to recover them without access to a single device. They seem to be intentionally reusing language traditionally reserved for security implementations where the private key is stored solely in a HSM with no way to export it, but that is not at all what is happening here. Security-wise, it's nothing more than a rebranded cloud-synced password vault.
Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors.
Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username. This is required for the intended single-click usernameless login, but the flip side is that an attacker would be able to discover all of your accounts by probing the token. Alternatively, the server would be able to discover an association between multiple accounts of the same person, destroying attempts to retain an anonymous alt account.
All in all, to me Passkeys looks like a thinly-veiled attempt to lock users into certain ecosystems, using convenience as a carrot-on-a-stick. Meanwhile, it adds significant security and privacy risks while claiming to be more secure. Seeing this being touted as a "more secure password replacement" by such major players makes me weep for the future.
Nothing about passkeys precludes you from doing additional security checks.
The challenge is that once you say "but an iCloud-synced passkey is not secure enough", there are very few options which are better - specifically because the attacker model requires either user participation or both an iCloud and existing local device passcode compromise.
Many sites are relying on SMS, TOTP, or email second-factor challenges, when the attacker already would have more than enough information to clone the TOTP from backup, to port the SMS number over (or just get the same push on a new device they control), or to read your email.
So unless you are doing in-person verification or relying on a secondary hardware-bound factor, there's limited "strength" utility in additional checks.
We are generally hitting the edges of what the multi-factor model can represent. All models have limitations. My opinion in particular is that MFA is meant to represent an organization's challenges for authentication factors, rather than requests challenging against an externalized authentication process with its own business logic.
> I am quite worried that websites will adopt this form of 1FA as the "new normal", compromising the security of anyone who still wishes to use secure passwords.
We can only hope. This is both more secure and more usable than what consumer facing websites do today, including many banks, from a user perspective.
The challenge is that an externalized authentication process will not map into risk mitigation processes or regulatory requirements today.
I suspect what will happen is that there will be a broad rollout, without actual security events, in a lot of verticals, and the statistics from that (e.g. phishing on password+SMS vs passkey logins) will motivate more productive reasoning on how new verticals can accept it.
> Sure, people suck at passwords, but even a poor password combined with an authenticator would be better than solely an authenticator.
Passkey-capable authenticators can do user verification, such as with a PIN or biometric. User verification is the expected mode of operation for passkeys. The challenges are that the site is abstracted away from understanding what steps were taken, and that a multi-device credential does not meet strong physical possession requirements.
Speaking broadly, there is a conflict between supplying a site with more control over the options which may or may not be supported in an authenticator, vs such control leading to sub-par user experience and even rejecting the user's choice of authenticator. I don't think anything will resolve this conflict other than time changing people's perceptions on what they need.
> Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature, but meanwhile vendors only allow syncing between their own devices.
There are capabilities to use devices across ecosystems. Generally this is done via a proximity-backed QR code initiated flow.
The expectation is that sites will allow for multiple registered passkeys against a single account, and that sites will be motivated to register an additional passkey for future local login if such a cross-device flow was used.
> Some of this could be mitigated by a universal pluggable passkeys backend, but I am not really seeing any substantial movement in this direction.
Android has publicly announced future plans to support such a thing, although I don't believe they have announced an approach or timeline.
1Password and Dashlane have both announced their web extensions will allow them to operate as passkey providers, and I believe both have now shipped at least early access code. I would certainly say the 'interest' is there to support pluggability.
> Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop.
How is this different than the state of password managers over the last decade? Both passwords and passkeys require local multi factor (possession of the mobile device plus a passphrase/biometric) to do any of these actions.
> I am also seeing a lot of misleading statements surrounding its security. For example, the claims that the keys are stored in a TPM/Secure Enclave. Meanwhile, in practice the TPM is only used for the local encryption of a copy of your passkeys.
In practice, it is quite a bit more complicated, including being specific to the device or software ecosystem.
On Apple devices, in addition to normal HSM clustering-style provisioning of new devices, there is support for a user-controlled paper recovery key. Like most implementations of cloud-synced vaults we've seen over the last decade, the vendor has no capability to read the data of the vault.
From an organizational risk perspective, there's no way you can legitimately accept passkeys when you can't evaluate their authentication policies or backing security.
From a user's risk perspective, they are 100% correct in assuming this is a secure system.
> If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course.
A workforce can do this by requiring the keys they provision, but it is not am acceptable course of action for a public-facing domain. See https://www.chromium.org/security-keys/ :
"To this end, public websites that restrict the set of allowed Security Keys should do so based on articulable, technical considerations." "If Chrome becomes aware that websites are not meeting these expectations, we may withdraw Security Key privileges from those sites. "
You must map your policy for what are acceptable security keys onto the _ecosystem_ of available attested security keys. Just accepting Yubikeys may eventually cause your site to lose access to WebAuthn API in certain browsers.
My understanding is that this is done so that early movers in the security key space (like a Yubico, who has proposed, co-authored or contributed to most of these specifications) don't gain market lock-in.
> This is required for the intended single-click usernameless login, but the flip side is that an attacker would be able to discover all of your accounts by probing the token.
The Web Authentication API does not provide a way to introspect which authenticators are available or which credentials they may store. Instead, the user is given some consent interface by which to release one credential on one authenticator.
Since credentials are also origin-bound, the only difference is that an attacker with malicious code on that origin could get you to release a credential without phishing any previous steps (e.g., asking you for your username and first-factor password login, so that it can see valid credential handles).
For CTAP, there are two protections. CredProtect prevents enumeration of credentials without user verification, so someone who gets your key cannot see the domain you have accounts on without further interaction from the key fob owner. Second, platforms have generally been locking down the ability for applications to directly interact with CTAP 2 interfaces, possibly behind an entitlement.
> We have literally spend a decade getting people to use 2FA
This still supports MFA it just also supports SFA. Requiring MFA 100% of the time is a guarantee for something people won't use even if it fits security ideals better.
> Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature
This one isn't as clean as I like either. There is a cross-device authentication flow, you can sign up multiple authenticators, and yubico has a backup authenticator proposal but none of these are necessarily ideal. I get not wanting to make the private key exportable for security reasons but if it's going to be allowed to sync on software authenticators over the internet I'm with you it should be able to sync between providers too. I'm not saying everyone should have to use cross-vendor sync I'm just saying it should be a capability.
> Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop.
You don't have to use external sync if you don't want and the standard still supports MFA on the passkey if you want but the truth is any solution that forces both of these 100% of the time will never see mass adoption.
> I am also seeing a lot of misleading statements surrounding its security.
I think a lot of it has to do with there being different levels of passkey store for different use cases. John Doe may want the convenience of just setting up a key on his phone and having it sync to all his devices for personal stuff but Jane Doe may need a hardware key with MFA for accessing the code repo at work and every option in-between. I don't think the security promises are misleading just maybe more complicated than one would wish because it's trying to be 1 way to cover all users and use cases not just "secure way" or "easy way for 1 particular device".
> Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors.
I don't know about "they are able to erect significant barriers to entry for any potential competitors" as the open passkey standard is specifically part of the next generation hardware key standard (FIDO2) rather than get locked into a proprietary hardware passkey format but I do agree it's the high-security way to use passkeys (as highlighted in my comments above). Not being able to export the private key, while annoying/disappointing in the cloud sync use case, is a hard requirement for the high-security use case so isn't an example of being there to provide lock-in. Especially with the ability to register multiple hardware authenticators for the same account.
> Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username.
I don't think the response contains any user identifying information. It does contain an opaque identifier the relying party can use to map to which user it was called the user-handle but that's not the user name it's a 64 byte sequence that can be mapped to a username if the other side already has it.