I'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
> use this to tether and lock you in to their platform.
You could say this about Google's proprietary authenticator app in the past, but now that they support Passkeys, arguably the opposite is true.
Importantly, you can now (with FIDO CTAP 2.2 and tunnel services [1]) use an out-of-platform Passkey to log into your account cross-device, e.g. you can use an iOS Passkey to log into an account on a Windows Chrome instance via QR/Bluetooth.
There's absolutely nothing stopping you from providing your own implementation as long as it complies with the "hybrid transports" part of FIDO CTAP 2.2.
The article says "Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN."
Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
As a user, that's sounding a lot like platform lock-in to me.
And as a developer, if I want a way for users to log in without a password, and I don't mind that login mechanism being reliant on the user's account with apple / google / microsoft - wouldn't I just add a 'log in with apple / google / microsoft' button to my login page?
No passkeys are just normal private keys. You can store those private keys in a particular platform's secure key store which on phones can be decrypted/made usable when you unlock the device. But there is nothing stopping you from transferring these keys to a different device if you wish.
> But there is nothing stopping you from transferring these keys to a different device if you wish.
Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone.
There's also nothing in the spec that forces any provider to allow transfer, so I don't expect that to change any time soon. And even if you can transfer your keys (which you can't) there's also nothing in the spec other than "please don't do this" language that stops a site from using attestation to restrict sign-in from other devices that you've transferred your keys to.
> Importantly, I don't think there's a single implementation of Passkey that actually allows this. In theory you could move your keys but in practice, there is no way to transfer your private keys off of your phone
The google password manager and Apple devices will sync private keys as part of the password manager sync fabric. They are on all devices.
In addition, the 'share password' option on Apple devices works with passkeys. To deter social engineering, the person needs to be in your contacts, and in proximity to receive an airdrop.
There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
> The google password manager and Apple devices will sync private keys as part of the password manager sync fabric.
This is really misleading -- you can not move a passkey "vault" from an Apple device to an Android device without doing a per-password operation. There are no Open implementations of a passkey authenticator and there is no standard format defined in the spec for how to do mass movement.
There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I mean, you bring up Airdrop. I feel like I need to check, is something changed and that now works on Android devices? I'd love to be wrong about this, but Apple's documentation doesn't mention airdropping a passkey to an Android device: https://support.apple.com/guide/iphone/share-passkeys-passwo...
That kind of platform lock-in seems like it would be an important caveat to mention when talking about backup. But I never see stuff like this mentioned.
I don't see how anyone could genuinely claim that passkey portability is exactly the same as an SSH key or password. That's just not true. Authenticating a second device per-site is not the same thing as a cross-platform backup.
> They are on all devices.
They're not on a Linux desktop. If you want to use passkey on a Linux desktop, your options are to authenticate through a secondary proprietary device or to use a Yubikey -- for all practical purposes a locked down device which can not be backed up (no, buying a second Yubikey and manually adding it site-by-site is not the same as backup).
> There's nothing (other than say future certification marks) to prevent software exporting via a CSV file, the same way many password managers export/import credentials today.
And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
And again, nothing in the spec requires it. This is asking for vendor lock-in. If it's not a big deal and everyone's going to support syncing across ecosystems, then it shouldn't be a big deal to add a standardized API and sync format to the requirements for being a certified provider.
> There are huge caveats to this that people are just glossing over and saying "yeah, they're portable, don't worry about it." It makes it really hard to trust passkey proponents when they talk about what's going to be supported in the future, because even the present support level is constantly being misrepresented. So how am I supposed to take their claims about what the future will look like if I can't trust them to talk about the present?
I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
> And yet, none of them allow it. I keep getting told that nothing is preventing this, but... it's not supported.
There also hasn't been anyone yet who has tried to define what that interchange format should be.
> And again, nothing in the spec requires it. This is asking for vendor lock-in.
There are a broad range of passkey providers, from open source hardware to FIPS certified solutions to solve government compliance requirements. Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
But those government agencies are specifically investing in that hardware because it _doesn't_ lock them into one vendor. Any other vendor who can meet their security requirements can sell into that space.
> I don't really see how this is different from the existing market of password managers, of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
Do you really not see the difference here? Passwords are inherently resistant to vendor lock-in in a way that passkeys aren't. And honestly, not to call you out but we're back on this again:
> of which many have already announced plans or released products (e.g. Apple and Google) to add passkey support.
This is not representative of what the ecosystem actually looks like.
Apple and Google have announced zero plans beyond "we're looking into it" to allow open interchange with arbitrary 3rd-party clients. Chrome on Linux doesn't even support native passkeys at all. The most hopeful development I've seen in this space is Bitwarden. 1Password was billed as the solution, but I don't see any plans from 1Password to support porting to other password managers.
And any of these platforms blocking 3rd-party syncing is a big deal. If even just iOS decides "no, we won't allow that", that alone is a huge vendor lock-in that needs to be acknowledged.
So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up? And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
> Is the worry going forward that _none_ of them will choose to support export/import or have documented vault formats?
My worry is that most of them won't, and that hardware attestation will get rid of the rest. Let's say there is a client that supports moving passkeys around. That still doesn't change the lock-in potential for all of the clients that don't, it doesn't mean users will be able to migrate to that client once they've been locked in. It doesn't mean that services won't block authentication using that client. A good standard should block this all off at the source; it should (to borrow from the Chromium dev team) encourage developers to fall into a "pit of success."
We already ran into this problem with 2FA codes on mobile devices. How long did it take Google Authenticator to support backup? That has impacts on the ecosystem beyond just "is it possible for someone who knows about the issue in advance to choose a client that's more open?"
> There also hasn't been anyone yet who has tried to define what that interchange format should be.
Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
I mean, they're the ones that want me to get rid of passwords. If they want me to adopt their solution, they need to have an interchange format. It's kind of their problem more than it's mine.
> Some of these would be very open to backup/restore, and might propose a format for doing so. For others it destroys their whole value proposition to their customers.
Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
Again, going back to this philosophy of the "pit of success" it should be harder to lock a customer out of backup than it is support portability. Portability should be the default, and it should be work to make that go away. And that's a key difference with passwords. It is work to make a password unportable.
----
At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
I would be more amenable to these kinds of conversations about the challenges of supporting arbitrary sync/export/import if I didn't have to start each of these conversations by calling out that arbitrary sync/export/import doesn't already exist. Because you're right, there hasn't been anyone who "has tried to define what that interchange format should be." That interchange format doesn't exist right now.
I don't think it's accurate or helpful if someone asks, "is this portable yet" to say "yes" when there is no interchange format and 3rd-party sync is an entirely theoretical future capability that companies are looking into, and there's outright resistance to building 3rd-party sync into the spec. Give reasons why that portability doesn't exist yet, sure. Promise about what will exist in the future, sure. But don't just say, "yeah, we're portable, you can sync keys" when both Safari and Android have huge limitations on when and where keys can be synced.
> So what plans can you point me towards where Google/Apple is announcing that they're going to build a generic API for exporting passkeys from the phone? Do they have a timeline up?
I'm not privy to their priorities or timelines, no.
> And no, per-login adding another device isn't sync. It's just not accurate to say that either iOS or Android are making serious progress towards portability. Their implementations are extremely locked down, and that's an important caveat that should be included in conversations about passkey portability.
But other companies with a history of being open here also do not have the feature yet. I am equally non-privy to their priorities or timelines.
If you want to say "passkey implementations do not have a bulk export/import feature, which makes it time consuming to switch between implementations", that is 100% factual.
I would not qualify this as a "lock-in", any more a phone that needs to get its software reinstalled is "bricked". And I wouldn't take current state to imply some inherent permanent ecosystem-wide rejection of user backups and data portability, when many vendors have implementations that are still in beta.
> My worry is that most of them won't, and that hardware attestation will get rid of the rest.
There is a great deal of worry about hardware attestation even by the vendors you are likely most concerned about. Apple for example not only removed their attestation, but now anonymizes the authenticator via a zeroed AAGUID.
No matter the vendor, their users (and the overall ecosystem) will suffer if relying parties build allow lists of acceptable authenticators, and deny all others.
That said, I do suspect the ultimate goal is to have sites be able to tell if an authenticator can allow them to shortcut additional authentication checks or not. It could be those websites give a more complicated authentication process to passkeys which do not meet their physical factor requirement.
>> There also hasn't been anyone yet who has tried to define what that interchange format should be.
> Isn't that kind of the job of a standard body? Is it actually unreasonable for me to ask the FIDO alliance to do that?
Putting aside that I can't speak as to whether there is or is not an effort underway there -
It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
If passkey providers hypothetically want an interoperable interchange format or protocol, they can try to standardize it in a number of places including under FIDO Alliance. Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
> Maybe it would be OK for them to use something else then? We're building out an authentication format that not only has zero protections to prevent lock-in, but that includes tools to enforce lock-in (hardware attestation). And I can't help but think, maybe it's fine for the extremely limited pool of agencies that need to block backup/restore to have a custom solution that's different from what Netflix uses.
I don't think this fixes your overall concern. There's no technical measure to prevent implementations from limiting backup/restore even if you make all authenticators anonymous.
Likewise, I don't believe websites would choose "friendly" credentials over "strong" ones. They would let the system survive or fail based on the user feedback/complaints of "strong" mode.
> At the very least, the conversation we're having now is a lot different from "oh, you can move your passkeys off of your phone." You can't, not unless you're sticking with the same vendor.
Yes, the process is automated within the same ecosystem, and we (finally) have a way to use a phone to e.g. authenticate to a computer and cross ecosystems. So far there is no process to batch migrate.
There _is_ a manual process to migrate. I get your desires and your concerns about users not understanding that they will have this multi-device process for migration today. I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
> I'm personally hopeful that there will be a solution here eventually to streamline switching platforms and passkey managers, once someone prioritizes it.
This is hopelessly naive.
We need to be actively making a lot of noise and sabotaging industry efforts to use passkeys until the respective vendors solve data portability.
> > Absolutely nothing prevents someone from creating their own bespoke backup/restore process in the meantime, which could very well get adopted by others.
How would they? None of the software involved here is Open Source, I can't open a pull request for any of this. And the backup/restore isn't going to work with any of the major players.
It's kind of striking that there literally isn't an Open Source provider supported on any of the major platforms. Let's say you build an Open Source one for Linux. Is it usable with Chrome? No, Google has no plans to support that. Does Mozilla have a working implementation? Also no.
Is that the FIDO Alliance's problem? Sort of? I mean, they want me to believe this is an Open standard. How many "Open" standards have zero officially sanctioned Open implementations of the standard?
> It depends on the group, but proposed standards for interoperability typically need at least two implementations - two parties have to commit to actually supporting the result. Actual standards need to show way more.
The FIDO Alliance has more than two members. Microsoft/Apple/Google are already in talks about how to build out passkeys. And they're the players that really matter here. Whatever standard they come up with (or decide not to come up with) is going to dictate how the rest of the ecosystem moves.
But again, they're the companies trying to tell me this is an Open replacement for passwords. I feel like it's kind of on them and their alliance to prove it.
I'm with you, Dan. It is grossly irresponsible for the industry to be pushing passkeys while fundamental problems like transferring from one ecosystem to another aren't solved yet.
We need to hold their feet to the fire and actively push people away from using passkeys until this problem is solved.
> actively push people away from using passkeys until this problem is solved.
I guess this is where I'm arriving, too. Passkeys are a nice idea in theory, but the whole thing is too early in development to use or recommend to others at this point.
So if I transfer a passkey to my Yubikey, which has a single button and no pin, thus achieving 1-factor authentication - is that undetectable to the website?
Because sources like [1] say that "A passkey can replace a password and a second factor in a single step" and "a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern" - isn't there something in the standard that ensures the second factor is maintained?
You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).
Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?
I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP and unenroll the keys you've lost custody of.
If the site insists on UV (User Verification) rather than UP (User Presence) a device which has no way to verify the user should reject that.
If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.
This is incorrect. Passkeys on iOS and Android are locked to Apple and Google account ecosystem. They cannot leave their ecosystem. Also, only the OS platform can use the BLE transport for CTAP2 protocol on iOS and Android devices. That is, a 3rdparty app (like 1password) cannot implement a FIDO2 BLE or NFC authenticator on iOS and Android – which is a huge handicap.
True, Passkeys are private keys at heart, but relying parties can verify whether they are stored in software or hardware by requesting/requiring authenticator attestation when they are created.
And certain hardware from certain platform vendors doesn't allow exfiltration of private key material. Though I don't think this can be specified by the relying party so that's how Apple stores all keys in keychai. I sincerely hope it remains best practice for relying parties to not require/use the platform attestation feature to lock users onto "trusted" platforms.
Device binding can be required by relying parties! They can just refuse to accept credentials without attestation statements signed by a trusted party.
My government e-signature service does that: I can’t even use a Yubikey, ironically, because that’s not "FIDO level 2 certified". I had to buy a more or less completely unknown brand instead (of which a government affiliate is apparently the exclusive reseller in my country…)
That's more like vendor binding. Apple’s credentials aren’t device bound so “pinning” to Apple as a vendor by requiring attestation doesn't ensure a credential is device-bound. Not that you don’t have a point, generally.
Ever site I've accessed with a passkey lets you tie it to an existing account with a username/password, Google login, Apple login, iPhone, YubiKey, etc. I've not used a passkey where that was the _only_ auth I could create on an account.
The title of the article though is "the beginning of the end of the password." Google seems to be making it clear here that they eventually want to get rid of other login methods, they just don't think it's mature enough yet for them to do so.
I don't see any indication that Google is looking at Passkeys as just a faster way to log in without a password. They want to eventually replace passwords entirely.
But they’re not the only one using passkeys. If you could have multiple passkey logins to an account, it’s not earthshattering if one of them becomes unavailable.
That's the intention yes, and it's a whole 'nother conversation about how many passkey-eligible devices people actually do have in reality, and how often they travel with all of those devices on their person at the same time and how often they're going to actually go through the extra steps of logging in on their secondary devices and adding a new passkey.
My parents are a good example of this, they have recovery options set up so that we can get into their accounts if they die. None of those recovery options are compatible with current passkey implementations, and their phones might be the only computers they have that are capable of storing passkeys right now. I myself have exactly one device that's capable of acting as a passkey authenticator right now (my phone) and I suspect that'll stop working if I De-Google it and then I'll have zero usable authenticators. I'm not sure how I would add redundancy to a passkey login without buying additional hardware. It's not like my password vault where I can sync it to basically any computer or flash drive.
But that's a separate conversation. Regardless, the goal is the elimination of the password, a lot of coverage and advertising has centered around that. Passkey isn't in the long run designed to be supplemental to traditional log-in methods, it's intended to replace them.
> Does that not rather imply that, if I log in with faceid on an iphone, my login will be tied to my ability to faceid on an iphone, and hence only available on iphones and macs?
The authenticator is given a lot of leeway in how it does authentication. In the Apple platform case, it is "the user authentication on the device which is on the iCloud account and has set up iCloud Keychain".
So on my Mac I can use TouchID. On my phone I use FaceID. Both allow me to fall back to the device password (such as when I have the lid on my Mac closed).
What it does imply is that if you store your passkeys on Apple's keychain, migrating to Android becomes that much harder. (I assume that Google will provide an implementation of passkeys on iOS when that becomes available as an API, but it will be a cold day in hell before Apple provides access to its keychain on Android.)
The solution is to not use Apple's keychain for passkeys (and really not use Apple's proprietary services for anything at all), but we can't depend on people to have that foresight.
You're suggesting that using a tunnel service is the recommended way to be a platform agnostic backend. But that doesn't cover the scenario where your password manager is running on the same device as the one where the user is performing the login, and all the UX/UI refers to using a phone to scan the QR code. I guess you could snag the QR code using platform accessibility features, but that's a real silly hack. Just let me advertise some mDNS service record for "authenticator" and require me to advertise a pubkey and let the user select/allow me once and remember the decision until the pubkey changes so that I'm trusted backend without the QR scanning rigamarole.
Yes, I'm waiting patiently in the wings. Sadly when I asked Apple's Passkey team about supporting this, they said it wasn't on the roadmap (though they carefully didn't say never, it still doesn't instill much hope). Once this missing piece becomes a required part of the standard, I'll stop holding my breath and get super excited about passkeys.
Not now, but soon. Bitwarden's public statements over the past year, and their acquisition of passwordless.dev, would seem to indicate that they're working very hard on adding passkey support.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is not what they want. They want to a) ensure passwords/accounts aren't being shared to ensure a single account is tied to a single user. They want this for all apps so they can recognize revenue for every user. b) They want more information on you as a user (as opposed to your family member on the same account). The wet dream is per-device, per-user profiles. Possibly even different [additional] costs for each attached device.
That is their goal. Big Tech all want this. That it increase friction to migrate is a side benefit (honestly not so much more than with passwords now). That it happens to benefit users is the lure to draw you in.
You don’t need to share them because you can enroll more than one for a given account. So for example if 3 people are sharing an account, you can enroll 3 passkeys for that account and they each have their own access.
I don’t see any way that passkeys kill account sharing.
What the other user says is that maybe those companies will only let 1 device per account to be registered. So you can’t have 2 devices to login. Harder to share.
In this case, Google, that isn't true and just they're mostly treated as special Security Keys ("yubikeys" etc).
To limit it to just one defeats the purpose of all this work. You really will only see that where there is a technical limitation (like... why does AWS only allow a single hardware key per user? If you setup SSO then you can have any number of keys)
It's not fear mongering to have and express concerns about a technology. Especially a technology that many people want to force everyone to use whether they want to or not.
In fact, it's important that people do this so that the invalid concerns can be put to rest and (hopefully) the valid concerns can be mitigated.
I think it's simpler than that. Expenditure is linked to trust. Companies and platforms that erode trust, make less money in the long run - they have to continually exert energy to attract customers. Companies / platforms that focus on building and retaining your trust have to work less hard to have you part with your money.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform.
This is the concern, but exporting passkeys to other ecosystems seems like it'll come with time, even if via third-party tools or like how browsers will prompt you to "import your <passwords|passkeys>" upon setup.
Call me a cynic but I'm convinced that won't be happening anytime before critical mass adoption of these companies' own solutions, and either defeated acceptance of this new norm or abject incomprehension by whomever remains.
I think they are referring to the EU's aggressive data surveillance and zero expectation of privacy to government organizations. While the EU has been very pro customer to business privacy they are vehemently against anything that lets anyone hid anything them the government.
I’m a cynic too, but I’ll also be optimistic about published statements. Goggle said they’re committed to supporting 3rd party passkeys when they announced android support. Apple, not so much though. I am hoping Google just does the right thing and makes this table stakes.
What you describe sounds awesome. Is it still something people could use? If the WebAuthn protocol gains broader support because Google/Apple are pushing passkeys then anything that speaks WebAuthn should be a viable option, right?
i say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers.
theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
> theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor.
Identity systems aren't too technically difficult, the challenge is properly rolling them out and getting mass adoption. Which means getting vendors/users on board. It's a problem solved by power and politics, not technological innovation.
I recall Mozilla tried something similar around a decade ago, which was a good solution but didn't get any adoption. There's also been approaches like OpenID which were once popular, where you can have a single login, but they have the problem of third-parties aggregating the sites you visit. Who uses OpenID today? It's all been replaced by facebook or google login.
Part of the difficulty of using secure credentials is sharing them between devices. It's easier to involve a third-party like Google who can do this for you. The big-tech doesn't actually want to solve the problem entirely because they want some form of control: Either locking you into their service, or aggregating the sites you log into, or both.
They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
> They also want your biometrics, and keep pushing the narrative that biometrics are for authentication, but biometrics should only represent identity, not authority.
The user giving authority to access their information.
Biometrics are not it. Anyone can forcefully grab your finger and place it onto your phone screen. They can hold the phone up to your face.
Secure keys or passwords (actual authority) are only vulnerable to rubber-hose cryptanalysis, but you can use plausibly deniable measures to reduce the risk.
But don't mix them up. The mind is more secure than the body because information cannot be forcefully extracted from the mind. Yet.
I think a better solution for authentication is a combination of a cryptographic key or seed and a passphrase held in the mind. Keys could be provided by an NFC ring or smartwatch, which should be more difficult to lose or have stolen than a phone.
Bitcoin has a nice solution for cryptographic keys with BIP-32/BIP-39. You use a single master key to deterministically generate all others via a HKDF. The single master key is produced from a 12/24-word phrase plus an optional passphrase.
A good opsec for bitcoin is to have several copies of a phrase (which can be etched into stainless steel), so there is no single point of failure if lost/stolen, and you can use several passphrases for different wallets, which you don't write down anywhere.
You can use a word phrase with no passphrase in a "decoy" wallet and monitor on-chain if any bitcoin are spent in it. This would alert you that your seed phrase has been compromised but would not compromise your passphrased wallets.
To replicate this kind of decoy with passwords, you could store a login for some service which emails you if anybody logs in.
The decoy method also provides plausible deniability. There is no way to prove that there exists any other keyrings with other passphrases, and there is also no way to prove that you have provided every possible passphrase, even if you have provided all of the ones you do use.
> What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
The value of many of these schemes is authenticating under your google/FB identity (email, phone number, org affiliations). It makes a lot of sense for centralized identity providers to do this because they already know who you are and how to authenticate you.
There is a growing untapped market for the authentication and secure use of of pseudonyms. For instance people that want to run a blog and interact in social media under a name that is not connected to their true name. Or some Senator wants to play video games but might be worried that it looks frivolous. This is a setting where something like MPK really shines. I believe over the next five years we will see an ecosystem around a pseudonymous web. MPK might have just been too early as that ecosystem isn't quite here yet.
You patent your things, then disseminate. Your ideas will be burglarized, stolen, reintroduced and shown as an invention of someone else (who is a lapdog of given entity).
The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are.
Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina. What are hardware tokens? They are physical devices that give you codes that verify that the person logging in has the device on their person.
What are passkeys?
Until they develop a way to explain what passkeys really are, I question how quickly they will be adopted.
> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone.
It looks like a token stored on your phone that will be used instead of your password to authenticate.
Apple did something similar: https://developer.apple.com/passkeys/ that is automatically sync-ed in iCloud Keychain, so on every apple device you own, you can use it.
So yeah it's sort of a token, but technically, it's a private key that is used to sign the challenge at login time.
EDIT: from what I understand, while this prevents from "stealing passwords" etc., there is still the risk that someone steals your private key (copy/paste your phone or ... well, steals stuff from iCloud Keychain) and tries to use that to sign the challenge. Did I get it right? Or what mechanism is in place to prevent it? It looks like this time we use biometrics first (to unlock the screen) and passkey later?
Because the word "password" has been in use for a long time, before computers, for the purpose of physically passing from one place to another.
The thing about password wasn't that it is a secret word, it's that it allows you to pass somewhere. Typically, passwords were a shared secret (i.e. not secret).
A digital key is typically different from a password in that it's not a word, i.e. not something people can remember a type. It's more like something you have than something you know.
In the context of cryptography it makes sense to distinguish keys from passwords, and public keys (used to "lock" data) from private keys (to "unlock" data). The word key is used for that concept because of the semantics of how keys are used.
A passkey is an abomination. A key, a-priori, is an object that opens locks; and we already have words for keys that allows you to pass somewhere: e.g. door keys.
A pass, in general, is something you present to pass somewhere, whether it's spoken or written; a key is not something you present to pass somewhere.
We have pass words, pass slips, hall/press/ski pass badges, etc.
We don't have pass keys, because you don't show a key to pass somewhere. You use it.
A password encoded as a QR code that you could show to a sensor would be a passkey.
I think the real answer to your question is a) marketing and b) it’s more data than just a private key. It has a private key, but also some other things.
Could be clearer for the tech folks though I agree.
The simplified terminology is not for you or I as technologists. It is for the general consumer market. Yes, public/private key cryptography has been a thing for decades, but it has been out of reach for the consumer market. The whole passkey idea is to reduce the technical and cognitive friction to make it a viable replacement for passwords.
> Passkeys created on Android are backed up and synced with Android devices that are signed in to the same Google Account, in the same way as passwords are backed up to the password manager.
I don't like this. Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration. I certainly don't like the lack of emphasis on interoperability from the get go.
> Time will tell if Google's implementation will be open source, and if third parties can hook into the OS level integration
It is all user terminology for Web Authentication features, so credentials stored on a current Yubikey are also "passkeys".
There are multiple open source security key hardware implementations that support the published specs.
There are multiple password managers that have started to implement "passkey manager" functionality - 1Password and Dashlane have made announcements here and have published code and Web Extensions for desktop.
Android 14 beta has a system API where software providers such as 1Password and Dashlane can work with this system, not just for Chrome but for installed applications.
I doubt Google's Password Manager will ever be open sourced, but it doesn't need to be for an interoperable ecosystem.
> but it doesn't need to be for an interoperable ecosystem.
what you described above doesn't guarantee that the ecosystem is interoperable. With passwords, there is no way for the service provider to hide the cleartext password from you, this is inherent to the way passwords work. With passkey, a service provider could decide to hide the private keys from you, effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
I don't know what a service provider is in this case for sure, but I'll assume you mean something like Google Password Manager or iCloud Keychain or 1Password.
There's no guarantee that they will act in a user-beneficial manner, except they all already exist and already act in a user beneficial manner, and that there is no strategic benefit of acting in a user-hostile manner.
> With passwords, there is no way for the service provider to hide the cleartext password from you
Sure there is. They could refuse to do anything but form fill the passwords on registration and authentication pages, where the field in the browser will not allow you to copy the password back out.
The force that keeps them from doing such user-hostile behavior for lock-in today is that nobody would want to use that system. They would not use that vendor. It would be product suicide.
> effectively locking you into their ecosystem, and there is nothing you could do to avoid this.
Unlike passwords, sites are encouraged to allow you to register multiple passkeys. Some sites may push the user to do this for convenience, such as if they see user utilizing a security key or phone to authenticate into their desktop when the desktop is capable of doing passkeys directly.
This gives a whole new ability to jump ship if you decide you don't like your software vendor.
Now, there is a parallel question of "what if a vendor uses their monopolistic power to prevent an ecosystem from being created, and then acts in a user-malicious manner". I suspect they would quickly get multi-national scrutiny.
You can, but most people won't because they will be locked-in, this is not the case with passwords as it's quite easy to change password manager without having to reset all your passwords.
I do too. The ability for a smaller focused company to innovate and pivot to find unique markets is way different than what the platforms will ever offer. I suspect passkeys provide new ways to innovate beyond what they have been able to do with passwords in the past.
Assuming there is an ecosystem where they can play equally, I suspect they will find all sorts of ways to provide unique value. Their goal shouldn't to be the preferred system across all of Android or iOS, but to offer something a lot of people are willing to pay for.
> AFAIK android will have an open API, iOS however is going to only support iCloud, classic monopoly.
The Android implementation allowing for multiple third part passkey providers (typically, existing password manager that want to support passkeys) is in beta.
Apple does not pre-announce features, so we are all likely in the dark on their timelines, and whether their timelines extend to infinity.
However, I believe a passkey manager can replace the system implementation via the web extension mechanism in mobile Safari today.
My understanding is that the private key is stored on your own device, unless you decide to use something like iCloud Keychain (which should be encrypted).
The public key, on the other hand, is stored on the service providers' servers. That is used to create a "challenge", which I guess on your phone you will need to "decrypt/sign" with the private key to prove that "it's really you".
Some devices e.g. Apple have a Secure Enclave that is not user accessible, that's what I'm referring to, I'm not suggesting that they are stored on a server.
Precisely this. What happens when Google decides that your account is banned, and no, we don't have to tell you why, and we regret to inform you we have automatically reviewed this decision and it is final?
Passkey is an open standard, clients are not limited to Android or IOS devices.
You can for example use a Yubikey, on a Linux desktop system, to authenticate to services implementing the "passkey" standard. Does Google own my Yubikey in some way that I'm unaware of?
Nothing is owned by Google or Apple or Microsoft, there is no grand conspiracy trying to lock you into a platform.
Try educating yourself before spreading misinformation, and before assuming that everything is an Evil Conspiracy by Big Tech.
Possibly a dumb question... the Yubikeys a bunch of us own were originally sold as U2F / FIDO keys. My understanding of this system was that it was, as labeled, a "universal second factor" standard. But passkey is supposed (?) to be a single-factor (something you have, not something you know). Is it doing this just by (ab)using the "second factor" approach for single factor auth? Or is there something a little more sophisticated, and hopefully more secure, happening here?
I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.
> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
I'd love to know more about how / whether these challenges are enforced as part of an open standard, or whether it's up to individual implementers of passkeys to roll their own.
I'm not sure why you couldn't associate a new key with whatever services you use, like changing a password, or even having multiple keys associated to one account.
Also I am not sure that I would consider not being able to access private key material from a enclave vendor lock in, since that's the entire purpose of the device.
I guess the same people arguing that passkey is a conspiracy are the same ones that think secure boot and TPM is a Microsofts conspiracy to prevent you from installing Linux.
Having to regenerate all your keys just to switch client is an order of magnitude (or two) harder than migrating from one password manager to another. The article we are commenting on is titled "the beginning of the end of passwors" as if passkeys were an improvement over passwords.
They are an improvement for service providers, sure, but not for users, due to vendor lock-in. This was my initial argument from the start.
You kept countering with arguments such as "you can use a FOSS client", "but Google is a contributor to open source" or "Google can't access your Yubikey" - which are irrelevant to my point, which is that the new standard introduces further vendor lock-in.
In addition you resorted to personal attacks - calling me and other users in this thread conspiracists or uneducated - but could not counter any of the points we were making with valid arguments.
I'm not completely sure, but my understanding is that it's basically the same principle as SSH keypairs, with the added twist that the user never gets direct access to the private keys.
The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.
Because the private key (in principle) doesn't ever need to leave the device, it could be stored in a TPM, Secure Enclave or similar chip. The device itself is also supposed to protect the key with some sort of local authentication, i.e. biometrics or a PIN. That stuff only happens locally on the device though and doesn't involve Google's servers in any way.
Consequently, if you want to log in from a new device, you can't just copy over the key - you have to perform some complicated dance where the new device and an old device that you have already registered work together to generate a new keypair for the new device.
If you don't have an old device, e.g. because you're a non-techie and only ever used your account on your phone and now your phone just broke? Though luck, I guess?
Same goes for blocking a key: In theory, you can block access for each device individually - however, you need to be able to access your account using one working device in order to do so.
(There is also the hilariously useless flow of "delegating" to a device, for when you're really really really want to check emails from your friend's phone but also have your own phone right with you in your pocket. It will not actually help you if you want to check emails from your friend's phone because you have forgotten your's. This feature sounds a lot like they needed something to respond with if someone asks about logging in from 3rd party devices - without making that usecase actually practical.)
So I guess all that does make stealing the private key somewhat hard: Phishing is out of the question as the user can't access the key even if they wanted to. Even if you got hold if the physical device, you'd have to get the key out of the TPM.
The bigger problems I see is that your account is now tied to your devices instead of, well, you: If someone steals your phone and manages to guess the PIN or get through the biometric auth, they have instant access to everything. On the other hand, if you have no registered device left, you're effectively locked out of your account.
(All that assuming if passkeys were the only option for logging in. As of now, they still seem to plan with passwords as fallback, so that's just hypothetical)
> I'm not completely sure, but my understanding is that it's basically the same principle as SSH keypairs, with the added twist that the user never gets direct access to the private keys.
Pretty close - in fact you can use passkeys for SSH access, a la "ecdsa-sk", and in some cases "ed25519-sk".
> The keys are also per-device, so e.g. if you use your Google account from your phone, your laptop and your workplace PC, there would be three public keys associated with your account.
They are per authenticator. Some authenticators, like a Yubikey, hold their credentials in hardware. Some are backup capable - e.g. the "authenticator" is your iCloud account or Google account's password sync fabric (which are often secured more than the rest of those accounts).
This second class is what is known as backup-capable. Buy a new phone to replace your old one, and within the same ecosystem things just work because the platform authenticator can see all your old passkeys.
Across ecosystems, there is the ability to use your mobile phone as an authenticator for other devices. You can sign into an app on a Mac desktop using an android phone, for example.
Going forward, Android has beta code to support third party passkey providers. Hopefully other platforms support similar schemes, which would allow users to choose a cross-platform product rather than being platform-locked (or requiring them to buy hardware).
Sounds like you are describing how hardware tokens are typically done? With this being an idea of how to move the token into the cloud?
I can kind of see the reasoning on why the browser wants to do this. Every one of them has a "generate secure password" feature bolted on, now. And I'm not clear that any of them have a way to port passwords out to another source.
Still feels a bit uneasy to me. Physical keys for property provide the kind of security that just doesn't cut it for virtual assets. Such that I'm having a hard time seeing any model without terrible failure cases. :( Super glad that isn't my day job. Good luck to them.
Well, guess it won't work for me. Rooted phone and prone to boot loops and hard resets whenever i get curious with some stuff. Every authenticator stored in the phone can't be recovered when you install a new ROM (google tries to send the authorization pop up to the previous version of the phone and, of course, it'll never get there)
Guess that's the price i pay for using the hardware in a slightly different way than what google and the manufacturer wanted me to.
> Rooted phone and prone to boot loops and hard resets
> using the hardware in a slightly different way
Honestly I wouldn’t classify turning a daily driver device into a semi-brick (if it boot loops and has to be hard reset regularly…) as “slightly different”. If you want to experiment that’s fine, but why would you subject your daily driver to that? Or, why not just have a phone for stable use / real world stuff, and a phone for everything else?
To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone — even those people who install custom ROMs on their daily driver — either plan around having to deal with this stuff or have an escape hatch. Most people refuse to tolerate such an experience.
My previous phone was a Xiaomi. Part of the reason they're cheaper than competitors with similar hardware is because that thing is filled to the brim with useless ads, extra tracking way beyond just crash analytics for the manufacturer and the regular google stuff and even some useless "phone booster" app embedded in the settings.
After waiting the two weeks so Xiaomi would allow me to unlock the bootloader (which is bullshit, by the way), i installed LineageOS.
The problem is that the regular updates with security patches sometimes would cause a boot loop. Some times is something as simple as a system file becoming read only, sometimes no thread on XDA developers could guide me to the right solution, and then i just do a factory reset and start over.
But aside from flashing lineage and an ad blocker, my usage is the same as anyone else: answer calls, use messaging apps, browse the web, play games and edit some documents when i'm far away from my PC.
My current phone is a motorola, though, and while i think the official ROM is pretty disappointing (too many pop ups nagging me to sign up to motorola or check motorola apps), as long as i can flash magisk and an ad blocker, i'm a happy person.
> To put it bluntly: you’re wildly out of touch with reality for most people. 99% of people who have a phone
I don't think 99% of people who have a phone have any kind of extensively worked out plan for what happens if their phone is lost, stolen, or breaks. If we're lucky the number is more like 50%. For most intents and purposes, irrevocably losing access to a phone is equivalent to bricking it in the way OP talks about. Any passkey-esque system needs to have a fallback plan when the phone unexpectedly becomes unavailable.
When you register a passkey to access a site, the component that holds the passkey generates a site-specific asymmetric encryption keypair. It then gives the site the (unencrypted) public key, and the private key encrypted with the passkey.
To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
A lot of what is interesting about passkeys is the supporting components that are available on popular platforms. Generally speaking, on client devices they store the passkey in special hardware so that the passkey itself is not available to the regular cpu. They also store it in the cloud, probably also in special hardware, and can send it to new client devices.
This all has some nice security properties, namely:
* sites don't have any information that would be useful in gaining access to a different site (reduced blast radius when any given site is hacked)
* the passkey is not available in the clear to regular programs running on client devices (hard for malware to steal)
* The client software ensures that the passkey is very hard to guess.
* The client software authenticates the site before signing the challenge. (makes it hard to phish)
Close - it is a signing key, e.g. used for integrity and authentication
> To authenticate, the site sends the client the encrypted private key and a challenge. The client uses the passkey to decrypt the private key, which it then uses to sign the challenge, then it sends the signature back to the site. The site verifies that the signature is valid and then lets you in.
This is how non-discoverable WebAuthn credentials (may) work, and is based on the U2F model. These hardware security key fobs did not have sufficient memory to store created credentials and associated metadata for potentially hundreds of sites. So instead, when you registered a credential it would generate a handle, and that handle would be returned to the site. To request authentication, you had to provide a handle which the authenticator understood. Such a model is really meant for second-factor authentication, e.g. after we partially authenticate the user with a knowledge factor, see if they have the physical factor.
A passkey in contrast is meant to indicate a discoverable credential. You don't need to provide those handles to authenticate. Instead, example.com shouts into the void (of browser javascript API) that it would love a previously registered credential. It hasn't authenticated the user at all, so it has no idea which credential that might be. An authentication response includes the handle and a signature, such that it can be correlated with the existing registration on a user account.
Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
I think you're right about discoverability being a key property differentiating Passkeys from WebAuthn credentials, I got that one wrong. I think the other ones would be it's likely syncable across devices, and likely requires some type of user verification.
You're probably right that if an authenticator is supporting discoverability it no longer makes sense to store the encrypted private key with the RP. It's still allowable though[0].
> Passkeys add in user verification as a capability so that you can use them for the entire authentication process rather than as just one of the factors. This typically means a biometric challenge or knowledge based challenge, such as PIN/passcode entry.
Thanks for this helpful comment, it helped me understand the difference between U2F and passkeys. I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected. (I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys, or would this necessitate buying a new device - if you're not willing to use your phone for the purpose.)
> I'm wondering whether these challenges (biometric / knowledge) are enforced via some open standard, or whether it's ultimately up to the implementation how / whether the signing keys are protected.
The WebAuthn spec describes a Javascript API, and CTAP describes how to communicate with authenticators over various transports (USB and NFC being the ones with the most implementations).
Actual conformance to these, requirements on behavior, and things like whether the hardware has mechanisms to protect certain types of attack if someone has physical access all fall into certification. The implementations can provide attestations, which allow a third party like FIDO Alliance to assert some level of certification (even if at lower levels the implementation details are self-asserted by the implementer).
Without certification, it is the manufacturer's word to the user that it has proper security and protections. Without attestations, there is no guarantee to the site requesting authentication that any particular process took place or that the credential has any particular form of security.
But the reality is that while we have built sophisticated _models_ for describing authentication and compromise risks, most consumer-facing infrastructure is a hodge hodge of password-backed accounts with email recovery.
The user already has full choice in how they manage passwords - from established to shady software makers, to a printout of an excel spreadsheet in 5 point font they keep in their back pocket. The SMS you sent out to verify the user's account may very well be protected by a carrier account with the same password the user supplied to you at registration.
> I'm also curious whether any currently existing hardware fobs implement enough of the standard to be repurposed as passkeys
Passkeys are "just" WebAuthn credentials with a couple of features - e.g. discoverability and user verification. With usability caveats (say, limitations around UX with NFC key fobs) I would expect hardware from the last 2-3 years to support passkeys just fine.
Support for new features may be added over time, both in software and hardware. For instance, a 2020 security key fob might only support a dozen passkeys, while a more modern fob might be able to store hundreds.
The term "passkey" is not a technical term, it is a user-facing term.
Passkeys are a better alternative to passwords. We don't have to think them up to meet arbitrary password complexity requirements. If a website gets breached it does not risk my account at other websites. It is phishing resistant, so I don't need to worry about accidentally using my passkey on the wrong website.
_We_ need to know more as implementers, but the average person signing into Google does not. It's an extension of the password manager experience, using technologies like public key cryptography and an authentication protocol rather than form-filling of text secrets.
For more technical details as an implementer, there are sites like https://passkeys.dev .
> Until they develop a way to explain what passkeys really are, I question how quickly they will be adopted.
The article is very frustrating, very long on fluff and no substance.
If anyone has a link to a detailed technical description by an unbiased third-party (not google hawking their lock-in), I'd be very thankful if it can be posted.
I suspect that one screen comic or a 20 second video could explain it. Instead they give us a wall of text that even technical people can't understand.
How about: "Passkeys are digital keys that can be securely stored either in a physical device (such as a Yubikey) or in an online account (such as iCloud Keychain or Google Passwords)"?
Thinking about this some more, maybe we should start calling Yubikey etc. keyrings, rather than keys, given that they can store multiple independent passkeys securely?
Don't be so quick to dismiss it. Afaiu, (one of) the problems they intend to address is the (all too common) case of breach of security at the server where large number of passwords are stolen. The public part of a passkey, i.e. the one stored on the server, is worthless to an adversary.
As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).
> You can either sync passkeys to an online account and across multiple devices, or use multiple passkeys stored in multiple physical authenticators.
But all of that has to be set up in advance, right? What happens if I really only have a single passkey, associated with my phone, and then lose the phone?
The upcoming W3C Web Authentication Level 3 defines a "backup capable" authenticator, which means that it goes beyond a single piece of hardware. Indicating "backups enabled" means that the user has a recovery process, such as if they store the passkeys in their iPhone and then lose/upgrade the model - they can just sign into iCloud on the new device.
Not all authenticators are going to have backups enabled (even ones which are backup capable), so these are really meant as hints so that a website (a la Relying Party in the spec) can guide the user to a proper experience. For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
> For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
But if you have this and the old authentication methods, doesn't that greatly reduce the security gains of this? I mean, the old methods still exist, so what you've done is increase the attack surface.
It can be used on both Android and iOS. Desktop machines can display a QR code which you scan with your device. Passkeys are backed up to the cloud using E2E encryption. If you get locked out of that device, you can do the same thing as when you lose your password.
> do the same thing as when you lose your password.
If this is a Google Service, then that means begging, pleading, threatening, crying like a baby, then finally posting a rant on HN to get the service unlocked.
Google is fairly infamous for making it near impossible to recover lost account access, or appeal bans.
I have an account that I’m never getting back. I made an error, when setting it up, that resulted in me losing the password (I saved the wrong one, in 1Password). It’s been a few years, but I remember trying everything to get it back, and was stymied at every turn.
Eventually, I gave up. The reason I registered the account, was because it was the name of one of my corporations, and I didn’t want fraudsters registering it.
Mission accomplished. Ain’t no one using that account.
In principle it can be synced between any is, it just depends on the cloud/implementation. Eg. 1Password is currently adding Passkey support, that would probably work on any device they have browser plugins and the private key material is stored and synced through 1Password vaults.
It's an open standard that allows a website to ask your browser for secure, authenticated, per-site-specific credentials. It's also a UI and method to provide those credentials and store them on your devices.
You don't have to use the latter, you can store your keys wherever you want.
Passwords will never be supplanted? As always, it's a false dichotomy. Passwords will continue to be useful for some scenarios, but in others they will and are being replaced by other methods such as biometrics, U2F tokens, etc
Biometrics should never serve as a password. It may serve as a login.
Passwords should be easy to retire and change if they are compromised. You can' easily change your fingerprint or iris circle on demand, if somebody makes a good enough copy.
I'm not sure if it is passkeys or other mechanism, but I can easily open my bank account on my Android phone just by using biometrics. Instead of typing a pin or password I just do the biometrics and voilá, it opens like magic. That really made me appreciate passwordless apps.
On the other hand, I don't really know how would that work on desktops, should chrome use a Windows service for that? Would it use its own servers? Apple would probably do it themselves. And how about Linux? Would a cross platform option ever exist? Maybe 1password?
I guess the idea is they will ask you to grab your smartphone the same way they do it for 2FA. For the end user it will be just like using the 2nd factor of authentication without the primary one (login + password).
I'm actually going to set this up on my mother-in-law's machine next time I see her. She's forever losing her book of passwords, but always has her phone on her.
This kind of approach generates your passwords for different sites based on login information and a single password only you know. No other passwords are stored on any devices or services, not even within the app on the device you are using it on.
Which enables you to have different passwords for each service and solves the problem of "too many passwords to remember" without just having to write them all down in a dozen ways that can also be compromised.
Passkeys are open, so you can for example store them in a Yubikey if you want. Else many password managers will soon support passkeys, for example 1Password or NordPass.
The protocol is private key stored on your hardware; public on the service you're authing to. Google doesn't have a way to MITM that, but if you lose the machine storing the private key, best have another way to auth.
(Note: some implementations, including Chrome on Android, do allow sync and sharing of the key, but IIUC even if Google bars you access to your account, the phone will still have the private key and can still do the login).
well, the argument is that for strong passwords you will need to use a password manager anyway. Which you will sync somehow, which will sync your passkeys too. So in the end you might as well replace all your passwords with passkeys except for the one password you use to access your passkeys in your password manager / the master access basically. The one way to make sure that you never lose access. I think this makes sense, I'm also very dependent on a password manager now.
Yes, the hardware vendor that controls the kernel and chips can do whatever they want. I meant there is no method as per the definition of the protocol to MITM the passkey because the device only ever emits the public key unencrypted.
I'm not sure how it's all that different from Windows Hello.
> Passkeys are easy to set up and let you securely sign in to your Google Account using your fingerprint, face, screen lock, or hardware security key. You can create a passkey on this device, or use another device.
When I press [Continue], Windows Security appears where I can then scan my fingerprint which I already use to sign on.
A single glide of my finger worked as expected and a 'Passkey created' screen appeared with [Done] being my only option to continue.
Windows Hello can supply single-device passkeys at the platform level. Browsers and native apps will leverage Hello in the background (a la WebAuthn.DLL).
A passkey is a user facing term. Platforms have been working on technology to support that idea for years now.
There may be a difference in terms of how Windows Hello dictates the user experience vs what browsers show on other platforms - I haven't tried it recently.
> What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina.
The key word being identify, as opposed to authenticate.
Authentication using biometrics is only secure as long as the object being scanned cannot be physically replicated and you can verify that the data source is a physical scanner and not a simulation of one.
How do you implement that without compromising device repairability?
> What's a password? A secret word or phrase that only you know.
No, a password is a secret word for phrase that both you and the service you want to sign into know.
I don't know how to explain a passkey but at least in this one sense, a passkey is split into a public and private part. The public part is shared, the private part is not. The public part can be verified to match the private part without sharing the private part. Your device stores this private part. When service wants to let you login they ask your device "does this public part match this user's private part?". Your device responds in a way such that the service knows "only someone who has access to the private part could have responded correctly to -should this person be allowed to login'"
> a secret word for phrase that both you and the service you want to sign into know
That would not be a password, that would be something you share. An actual password must be possible to verify without it being stored on any device. On the service side, it's the same as for certificates, as you describe. The service can't store the password because that would invalidate it's usefulness as a way to prove someone is who they say they are. This is why we store a cryptographically secure hash code instead. It is also why the password hash code must be generated on the user's end, not on the service side. You never want to "transmit" passwords in plain text because transmission across the internet is an act of making copies of the data transmitted in the memory and storage of all the devices it transmits across. The moment you send a password across the internet, it is compromised.
So as the service, you don't know the password, you only know that the hash code you received matches the one for that user, and you are reasonably certain that there is no known way for someone to generate that hash code without knowing the real password. Therefore the person trying to login in must be who they say they are.
Passwords and private keys only work as authentication if no one else knows it, has possession of it, or can get access to it. If there is a flaw in any one of those aspects, then the system doesn't actually prove a person is who they claim to be. It only proves that a person is someone who knows, possesses, or has access to that thing. That might still count as evidence that they are authentic, but more will still be needed to actually prove they are authentic.
Agreed, I think we have to move past the general assumption that people do not understand anything written in terms that are even remotely technical. Obviously HN is a tech savvy audience but still software service providers should provide greater clarity into how things actually work and encourage users to think about things more technically instead of just making everything a magical black box.
If people here can't understand what passkeys are, how are the "normies" gona get it? Or maybe the wide public is not supposed to get it how it works; they should "simply" use it.
The second. The term passkeys is meant to describe "like what I get with passwords, but easier/more secure'.
It's lowercase "p" - it isn't a Google or Apple brand.
Developers can use terms like "multi-device discoverable user-verifying FIDO/WebAuthn credentials" which have very precise technical meanings with demonstrated interoperability.
They will understand their password has been replaced by fingerprint reading or pin on their smartphone. They won't bother with the technical aspects behind it.
And they will be fine with that because they have already been introduced to this because that is the way they authenticate locally with many apps on their smartphone already.
i think you underestimate how many users want to just be signed in to their account, and don't really give a damn about security in any way. they see a password as an inconvenient impediment, and if they could get rid of it tbat would be fine.
keeping your data secure is google's job, not the user's. if google stops asking for a password, that's going to make people happy and they're not going to ask a lot of questions about why.
For a technical standpoint it's a system that generates OTPs from another Auth source, like biometrics or even a classical password.
From a practical one it's another way to get people to relly on major comporations for all Auth ises so they yet have another thing anchoring to their ecosystem.
WebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards.
At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures.
I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requirement to opt in to it) to the W3C WebAuthN working group, but it seems like the working group itself is strongly pro cloud synchronization as well.
Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator in favor of (iCloud-synchronized) Passkeys, and I guess I'll begrudgingly have to switch to using an external FIDO authenticator instead.
> If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.
Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co. ("roaming authenticators" in WebAuthN/FIDO parlance).
Unfortunately, only Android is planning to offer [1] a first-party Passkey provider API, because that's what I'll probably be using 99% of the time (finding my external authenticator for every login is frustrating).
> Also, Passkey providers now get sweet sweet metadata about your accounts around the web.
To my knowledge, both Google's (for Android) and Apple's sync backends are end-to-end encrypted. I'm not sure if that includes the metadata as well as the private keys, though.
> Fortunately, both iOS and Android also support "detachable passkeys" a.k.a. Yubikey and co
That’s good to know.
Although my concern would be, that’s really good for people who use YubiKeys, but regular people won’t, and they can then get bitten by account lockouts.
Is there something regular users can do to use Passkeys (let’s say they use Google) and have some recourse if Google locks them out?
Also, what happens if they use Android, have no other computing device (this is fairly common in some parts of the world), and their phone gets stolen?
Right now, the identity of an account is tied to knowledge of the email address and the password. Something you know.
If you forget the password, you need access to the email account.
With passkeys,the identity of the account is tied to either a BIGTECH account, or to physical devices.
If BIGTECH locks you out or you lose access to all your physcial Yubikeys at the same time, you will never access the account tied to the passkeys again.
Agreed. This whole thing seems incredibly user hostile. At the very least, there should be severe legal recourse (criminal liability and also large, material-to-earnings statutory damages) if one of these providers intentionally locks you out of a third-party account.
That third party account should be treated like your personal property, and them denying you access to it should be treated like their CEO breaking into your house and stealing your stuff.
If they don't want to take on the liability, and it kills the passkey spec, that's fine with me. The current system avoids the issue by allowing people to store credentials in a decentralized way.
Lol. If something does happen Google will immediately and repeatedly remind you with every communication that they have no liability. Once your account gets flagged or locked, Google adds the following to damn near every email:
“We have concluded the review of the information you’ve submitted. To prevent possible fraud and abuse, your services will remain suspended. It is our policy to not discuss the specific reasons for these suspensions.
Note that in the Google <PRODUCT> Terms of Service, we reserve the right to change, suspend, or discontinue any aspect of our services at any time, including availability of a service or any feature, without notice and without liability. We also reserve the right to impose limits on certain Service features or restrict access to some or all of the Services without notice and without liability.”
Giving your passwords to a company that cares about money more than you is risky. But losing devices with passkeys is a big problem too. Even if passkeys are saved to your Google, Apple, or Microsoft account, if that account itself is behind a passkey, how do you access it if your phone holding the key breaks? If a disaster or fire happens, all your devices could be gone.
Passwords are good because you remember them in your head, so long as the head works, so do the passwords. This might be an obvious statement, but it's clear passkey providers kind of glance over it.
I don’t know about privacy, but the lockout risk doesn’t seem worse than losing your phone or Yubikey. You should have multiple independent ways to log in for any account you care about. Passkey will be one way.
Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)
What if one loses all their devices in a natural disaster, a house fire, or burglary, or lost baggage while traveling?
A password is in your head. If you lose that, there's not much use for the said password. But otherwise, it's secure. And it's pretty secure from an infosec perspective if it's a passphrase.
I think it's more likely that you'll lose your password by forgetting it? People forget many things without losing their heads.
There's no perfect solution. Having a printout of backup codes in a fireproof safe is pretty good, but it's of no use while traveling. A Yubikey is good, but it might not work (wrong USB port) and it's a device that could break.
Having multiple ways to log in reduces your risk of lockout, but also makes it more likely that someone unauthorized could get access.
Passwords, particularly passphrases, are easy to remember and you can reuse a similar structure for probably decades:
- There-are-three-ducklings3-in-the-lake
- There-are-five-swans5-in-the-lake
- There-are-six-hedgehogs6-in-the-bush
And so on. You only need to remember the latest number and animal, but the entropy of the whole string is much higher unless someone also knows your personal password structure (which is kind of like a second factor).
With a password manager, you only need to remember that one passphrase. If you have to enter it daily, I think it’s very difficult to forget.
You can access your passwords mostly independently from any device and it’s probably about as secure if good generated password hygiene on websites and services is used.
You are right, choosing the right one (reading its whitepaper and what encryption it uses where), and backups are very important for those. I suppose logging into all of the services we use these days is complicated and not very secure no matter the method.
So if passkey is just yet another way to log in, then all the security aspects are moot, no? The attacker could still attack the other login methods. E.g., even if the passkey is a secure surface, it does not replace the insecure attack surfaces.
Personally I don't want to be dependent on a third party like Google or Apple for my identity. That's never going to be acceptable.
If they just accept normal Yubikeys (and multiple at a time for redundancy) that'd work for me but this passkey stuff where the vendor gets to decide things and I don't fully own my credentials is just wrong IMO.
I wonder if there's a fully self hosted passkeys option?
I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like. But Fido gives a lot of control to websites, they can choose what kind of authenticators or apps to accept. This can make it too easy to get locked into vendor solutions because they are the only ones every website trusts.
> I wonder if there's a fully self hosted passkeys option?
If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!
For on-device passkeys, at least Android is preparing an API for this [1]. I hope that iOS will follow at some point, as well as Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).
> I'm also opposed to attestation. With TOTP I can use any app I want and back up my keys however I like.
In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
Of course, it's being already exploited in a pretty much expected way: My government offers a (free to end-users, tax paid) e-signature solution. They support, among other authentication methods, FIDO – but only a very specific authenticator, of which the e-signature service provider is the exclusive reseller in the country...
> If external authenticators work for you, physical keys (like Yubikey, Solokey etc.) are arguably self-hosted!
Yes. And this is what I do with all my personal stuff (though I use the GPG mode on the yubikey, not Fido2). But, because a passkey can be backed up, websites targeting mainly passkeys will be likely to offer only a single authenticator to be enrolled. Of course with hardware authenticators that is not going to work. Lose that one and you're screwed. This is why multi-authenticator support is so important.
> For on-device passkeys, at least Android is preparing an API for this
Thanks, I'll have a look at that. I'd want it on the PC too though (BSD). But anyway, hopefully it will come. I never really looked at it, as for now the website acceptance part is still so low that it didn't matter anyway. For the ones I use regularly, only Office 365 supports it. I'm not interested in the old FIDO MFA mode, only full passwordless will do.
> Firefox (which unfortunately has been quite slow to adopt all aspects of WebAuthN).
Yes, this is really a PITA now. They really don't seem to give a ***, they only offer CTAP2 (full FIDO2 + PIN) mode on Windows. Still not working on Mac, Linux, BSD... It's been in this sorry state for years now.
> In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
Banks here already use their own authenticators which they provide anyway, but yeah that's a point. Many other sites shouldn't be able to make such decisions though, IMO.
PS: I'm not sure why you are being downvoted, I really appreciated your insightful comment. Especially about the Android option I wasn't aware of.
This page has a recent comment from a Mozilla employee on Firefox support:
04-24-2023 04:39 AM
We are actively working on supporting this feature.
Here is our current roadmap (might change):
- WebAuthn Level 1 + CTAP2 is riding the trains for Fx 114
- WebAuthn Level 2 + 3 are planned to ride the Fx 116 train
- Passkeys (though details are still about to figured out) earliest completion is Fx 120
So, it's coming but it's going to take at least six months or so. Current beta version is 113.
Hmm that's nice actually!! Because I only need the first one and perhaps the second, I will not do full passkeys until it becomes possible to self-host it anyway.
I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.
> In principle I agree, but some service providers like banks are legally liable for fraud losses (at least in some jurisdictions). I'd say they do have a legitimate interest of being able to verify which authenticators they trust.
I have yet to see a bank use login restrictions to make itself more secure. I've been trying to get my bank to offer actual 2FA for years, and their response is that they moved from offering SMS/Email codes to only offering SMS codes.
A bank should not have control over what authenticator app I'm using. Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app. In practice, this is just a way to make it so that DeGoogled devices, Linux devices, etc... won't be able to interact with normal services because they're "less secure". And the companies saying that will be the same ones asking me for authentication over the phone via my mother's maiden name. They don't need this, they're not technically qualified enough to have this level of control over what devices I use.
I honestly don't think attestation should have been part of the spec at all. There is an extremely narrow range of instances where knowing what client/hardware/OS someone is using is justifiable, and in almost all of those instances you should probably be directly controlling the hardware itself (providing a phone for your employees, installing a kernel module, etc...)
And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.
At least today these services all offer websites so I can still log on and use them without installing an app. But with attestation we're moving towards a future where you won't be able to log into your bank unless you own a "supported" Android device or an iPhone, and rooting those devices will mean that you don't have access to online banking services all of the sudden.
> Their authenticator apps that they do have are terrible and my security would be improved if I could just use a simple 2FA app.
Good point. I was at my bank last year to discuss a mortgage. It's already a bank I don't feel so good about because their idea of "authentication" is to type a 2FA code that you get from the bank app into the bank app (so you have to type the code in the same app that just gave the code to you!). This really feels like busywork rather than real security.
But anyway was she sat down I saw her log in from a Windows 10 endpoint into a VDI system that was clearly Windows XP (or 2k3 server) judging by the login screen and window decorations. Sigh... I have serious reservations now about leaving my money there.
Of course VDIs are sometimes considered more secure but at my work we have really come back from that idea. Back when wannacry hit on a friday afternoon most laptops had already left the office for people's homes. But the VDI servers were online 24/7 and constantly kept getting re-infected and spreading malware throughout the network.
> And there's nothing official to discourage companies from using attestation other than some vague "but don't do this if you don't need to" language. It's a bad idea that will be used to restrict people's control over their own devices that they own.
Totally agreed, this is also the problem I have with attestation.
How is this different than a password manager with encrypted cloud backup? Your recourse if someone breaks passkeys is legal, not technical. Security must be a balance with functionality, and this is a huge improvement over passwords. (Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal)
Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
The difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!)
Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time.
> Security must be a balance with functionality, and this is a huge improvement over passwords.
Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out.
I must be missing something but I do not get all this hand-wringing. Don’t like the passkey options from Google or Apple? Fine! Use the hardware authenticator you absolutely already have if you’re the kind of person who has these sorts of objections.
Sure, I already do that, but why shouldn't there be a choice in on-device passkey implementations just like there is for password and HOTP/TOTP authenticators?
Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS. There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
It would encourage competition in both functionality and security, it reduces reliance on a single account your entire digital life, it allows niche products to address special requirements in all kinds of scenarios...
> Your argument sounds a bit like "Don't like Safari? Just use a different OS then" in the context of allowing browser choice on iOS.
Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
> There is no technical reason a Passkey provider and OS/platform should be necessarily bundled.
Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
> Except… you can just use a YubiKey. It’s closer to saying “install Firefox” than “install a different OS”.
No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
> Sure, fine. This is like V1 of every provider’s implementation. None of this was even available three months ago, I have no doubt these things are coming.
On iOS, Passkeys have been available for more than half a year now. I really hope that Apple will eventually follow suit.
> No, you're literally recommending I use a separate physical device because there is no API to achieve the same functionality that the OS provides via their bundled implementation.
A $50 device that I have no doubt you already own, and that does not require you to change or modify any of your existing computing setup or habits.
If your point truly has merit, you shouldn’t need the hyperbole.
I agree there should be a way to opt out of system level ecosystem passkey sync with a big ol’ “you’re fucked if you don’t back these up somewhere” click through warning.
That's exactly what I want, ideally at a per-passkey level.
It should also be able for relying parties to express that desire (whether opt-in or opt-out by default). As it is, I think it'll just make banks and governments less likely to adopt passkeys.
That's sad, because all in all I think WebAuthN has the potential to have a very positive impact on security globally.
If a platform gave users this option per credential, and there was any visibility to that choice on the relying party side, the replying party would likely just reject the credentials they don't like outright, and tell people 'go figure out how to twiddle this setting if you want to use your phone here'.
Part of the web focus of these APIs mean that they will default to being open and user centric - features that might enable relying parties to block user choice will receive tremendous scrutiny, and proceed very slowly. Sites are expected for now to accept what the user chooses, and do additional steps as necessary to meet their needs. This means passkeys as a whole are not going to be always accepted as a MFA replacement.
Even features like hardware attestation are gated by a prompt by some browsers, because some consumer-facing websites went live with code saying "we will only support this one brand of security key". This led to some of the warnings in the document here: https://www.chromium.org/security-keys/
I can sympathize with the desire of a "footgun mode", which might even lie to the website about whether the credentials are backed up. However, I wouldn't trust something that critical to what is almost going to be a poorly maintained path through the system. Instead, I use (two) Yubikeys for such credentials.
Yeah this is fair. It blows my mind that platform players don't understand that the security posture needs to be configurable at a per-credential level. The hope would be that 3rd parties step in and provide implementations that afford these options to users, but that would require platform players to stop dragging their feet on allowing PW managers to hook in to WebAuthN challenges as a credential store/backend.
Yes, being able to choose my own password manager is indeed an important feature to me. I'm pretty sure that feature is not unique to closed platforms, though.
> Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal
Wonderful. Until every second web service starts to require a signature from such digital identity ("age verification" perhaps?) and that's the end of pseudonymity.
> Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator
Local-only iOS+macOS Codebook sync (open-source encrypted! by SQLCipher) provides password and TOTP convenience, durability, transparency, decentralization and fewer supply chain dependencies with one-time purchase. Founded in 2005.
Passwords and TOTPs are not MITM-safe, WebAuthN/Passkeys implicitly are. (Credentials are bound to a specific RP, i.e. it's impossible to accidentally provide one to the wrong website or a scammer on the phone.)
> Codebook links passwords to specific websites/RPs. Some people don't take phone calls from random callers.
Sure, but passwords are still multiple-use, and sometimes auto-fill fails (often due to websites actively messing with it), requiring me to manually copy-paste the password and exposing me to phishing risk, or that of insecure/malicious applications on my system sniffing the clipboard.
> Can Apple allow existing password managers like Codebook to manage passkeys and synchronization locally?
Unfortunately not at the moment. There is some hope though, given that Apple has recently added a TOTP API for third-party authenticators, but I'm personally not holding my breath.
> Codebook links passwords to specific websites/RPs.
WebAuthn is different:
1. The client (browser) knows which site is requesting credentials, which means a phishing site cannot ask for another legitimate site's credentials
2. Credentials are created as private keys and unique per-site.
3. The authentication protocol does not share secrets; it is based on public/private keys.
4. The authentication protocol involved indicates the requesting origin.
There are still vulnerabilities if you have compromised DNS or javascript on the site, but it is overall significantly stronger against phishing and credential reuse attacks than password managers could provide before - even those with browser integration.
You have the option to use a non cloud password sync method today. Best of all, that can sync a single password or private key across multiple vendors. This locking down inside bubbles really needs to go for me to want to use passkeys, I don't want to register 3 separate passkeys for each account I want to register 1 and sync them between my devices.
Agreed I'm not the average user but what does that have to do with the passkeys not being exportable between devices/clouds and instead being forever locked into only that vendor's cloud? The average user does not own only Google or only Apple or only Microsoft products nor do they want to enroll every account for every new device manufacturer key store instead of have options to use something else. This isn't predicated on existing use of a password manager it's just also a downgrade from that aspect of them.
For the client-side, the spec is comprehensive in allowing the authenticator to decide whether backups are allowed. In this case it's iOS not exposing that to you as a user. I get why you'd want this, but trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say, and definitely not in Apple's own interest to support, to your detriment.
RP-side, it's true that RPs can't opt out of credential syncing, but I think that would be weak at best, as the authenticator can do what it wants. The RP can use attestation and the DPK extension to effectively bind authentications to the same originating device.
> trusting Apple to store your single-device passkeys for high-stakes credentials but not trusting them for syncing them is somewhat of a very specific threat model I'd say
I don't think it's that specific of a threat model, to be honest.
Many people are logged into iCloud on multiple family devices – are they aware that with Passkeys, by default every device they are logged in to has single-factor access to their entire online life?
> Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator
Is this the TOTP authenticator app that Google only started actively maintaining again in the last year or so? If that's the case, that's pretty funny timing.
What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.