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.

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.

[1] https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-cl...

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?

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.

It is very locked down right now.

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.

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.

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.

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.

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.

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.

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.

We need to hold their feet to the fire and 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.

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?

[1] https://developers.google.com/identity/passkeys

edit: spelling

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.

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…)

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.

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.

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).

Android will provide an API for that scenario (i.e. on-device third-party authenticators) in the near future [1].

Hopefully, iOS will do the same.

[1] https://developers.google.com/identity/passkeys/supported-en...

I can't rely on retaining access to my Google account for logging into things.

1Password has already announced their intention to use this once ready. I really hope iOS will provide something similar soon.

There's many implementations of OTP. I've never used google's and I've been fine.

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.

https://support.apple.com/en-gb/guide/iphone/iph0dd1796bb/16...

I don’t see any way that passkeys kill account sharing.

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)

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.

https://developer.apple.com/passkeys/

https://arstechnica.com/information-technology/2022/10/passk...

Now I'm wondering what's the longest class name out there...

The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace:

  com
  └─sun
    └─java
      └─swing
        └─plaf
          └─nimbus
            ├─...
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePanePainter.java
            ├─InternalFrameInternalFrameTitlePaneWindowFocusedState.java
            └─...

• https://news.ycombinator.com/item?id=4549685

• https://news.ycombinator.com/item?id=4770861

Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...

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.

"All your base are belong to us"

How so? I just created two passkeys for my Google account — one for Chrome, and one for my Apple Keychain.

Disclaimer: I own 2 NFC rings :)

We have a lot to talk about and exchange information.

greg at the domain qbix.com

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.

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.

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.

What does "authority" mean here?

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.

Both are bits of data stored in the body (including mind and pockets) that suggest the owner is giving consent.

They both have flaws, but what are the alternatives?

The mind provides authority.

Use both!

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.

There are payment rings a plenty though, for just using them instead of contactless credit cards.

So it should be easy for everyone else to do their own.

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.

More information here: https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/

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?

They don't need to be rebranded, they need to be taught in high school with the same words we've always used to talk about them.

You cannot use the private key within a passkey for general purpose data signing, for example.

The answer is that they're being used to pass an authentication challenge. Pass + key is no different.

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.

Whatever Google has is probably something else.

https://developers.yubico.com/Passkeys/Passkey_concepts/Sing...

I wouldn't be surprised if password managers implement sharing between users tho

Could be clearer for the tech folks though I agree.

this isn't just public key encryption. Think of it as a physical Yubikey but embedded in your ...whatever.

How convenient!

> 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.

I do not like this future.

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.

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.

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.

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.

This is not a remote possibility. It happens to thousands of people every day, for entirely frivolous reasons.

Until there is some authentication system that is genuinely robust to corporate control attacks, I'll keep using the imperfect password manager model.

Also it seems that Linux is completely out of the picture.

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".

That's how I understand it.

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.

I tried to do some research myself, but there's no Wikipedia page for "passkeys" and they aren't mentioned on the Yubikey article.

Edit: this user has a helpful comment: https://news.ycombinator.com/item?id=35810144

> 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.

The list of members of the FIDO alliance is public. It includes several companies that most people refer to as “big tech”.

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.

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.

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)

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).

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.

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.

> 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.

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.

So, a communication failure straight away. Does not bode well.

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.

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].

[0] https://www.w3.org/TR/webauthn/#credential-id

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.)

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.

https://developers.yubico.com/Passkeys/How_passkeys_work.htm...

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 .

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.

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?

It seems to be smoke and mirrors for you register a bunch of TPM/HSM.

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).

What happens if user loses the only device on which passkey was enrolled?

Yes!

> What about desktop machines with no fingerprint sensor or faceID?

You can use a PIN, your login/screen lock password, or an external device offering a fingerprint sensor.

> What happens if user loses the only device on which passkey was enrolled?

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?

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.

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.

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.

* Easy to understand. (A password is just a word/phrase/string of characters only you know.)

* Easy to use. (Using a password only requires remembering and typing it in when prompted.)

* Convenient. (Only your ability to remember and type required. No other tools or gadgets required.)

* Simple. (All of the above.)

If something needs an essay to describe itself, it's not killing off passwords.

Do you really want your only means of logging into a service identify you because it's also the only way you log into your banking?

And should you want to kill off an identity so you want to have to register everything?!

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.

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?

* Easy to understand. Your device will just ask "sign in?"

* Easy to use. Your device will just ask "sign in?"

* Convenient. Nothing to remember, nothing to do

* Simple (all of the above)

Passkeys are/will-be way simpler than passwords for the majority of users

Or if you drop your phone in a lake you’re out of luck too.

You use passkeys as a preferred login method.

If you do not have your passkey, you can tap "Try Another Way" and use your password as usual.

It just becomes much harder to phish out this password.

If you've also lost access to your email, you've got other problems.

Or better still, use a password calculator app such as https://spectre.app/

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.

https://www.yubico.com/blog/a-yubico-faq-about-passkeys/ https://nordpass.com/passwordless/ https://www.future.1password.com/passkeys/

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).

right, so passwords it is then.

One of the main gripes people have is about whether or not the user actually has access to the key or not.

ie. Can I save my passkey somewhere that I control, can I login on another device, etc. etc. Or do I need google's sync/account to do that for me.

Google controls the software so it can MITM.

> 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.

After a sign out, re-enter of my gmail and these are the next few steps: https://imgur.com/a/heLrUkb

It seems like it just integrates the built-in verification methods depending on what device you are on.

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.

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?

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'"

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.

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.

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.

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.

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.

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.

[1] https://github.com/w3c/webauthn/issues/1714

If Google/Amazon/Apple/Meta/whoever locks your account out, you now lose access everywhere.

This isn’t a theoretical risk. You’ll see lots of people complain about this online.

Also, Passkey providers now get sweet sweet metadata about your accounts around the web.

But yeah, authn is hard to do right. Equally, asking your users to fall into $BIG_PROVIDER’s arms seems wrong.

My personal hope is that various accountable nonprofits will begin to offer passkeys.

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.

[1] https://developers.google.com/identity/passkeys/supported-en...

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?

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.

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.

“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.”

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.

Possibly two ways, if you have both Android and iOS devices and you register both? (I assume Android and iOS remain independent.)

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.

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.

- 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.

I’m not sure this is better than using a device to log in.

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.

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...

[1] https://developers.google.com/identity/passkeys/supported-en...

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

I really hope it will come to all platforms though. Not just Windows or Mac but also Linux and BSD.

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.

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.

Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.

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.

[1] https://support.apple.com/guide/iphone/sign-in-with-passkeys...

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.

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...

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.

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.

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.

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.

This is what you expect when you buy into the closed Apple ecosystem.

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.