[thewebguyd]

> It seems like everyone wants to be _the_ password manager for all your passkeys.

Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised.

Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

[dotancohen]

  > Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

I have just shy of 2000 site credentials in Keepass. Let's assume that they were all Passkeys.

1) When I buy a new device, how do I create 2000 new Passkeys for that device?

2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.

3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?

[crote]

The original U2F tokens didn't suffer from this problem that much. It contained one secret, it relied on the website to store and return an opaque website-and-account-specific blob, which was decrypted by the token and used to sign the login request. It would be reasonably easy to expand this in a way where the server also stores a backup credential for use by your second/third/whatever hardware token, encrypted with an asymmetric key during the enrollment of the primary token.

But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

[chimeracoder]

> But this went out of the window when some genius decided that usernames were too complicated, so Passkeys had to be discoverable, which means they have to be fully stored token-side. Which of course has the nice side benefit of essentially killing hardware tokens and forcing people into using their Android/iOS/Windows device for it.

This part of your comment is incorrect. Discoverable Webauthn absolutely can be used with hardware tokens like Yubikeys.

[omnifischer]

This. I would have loved if this original u2f existed. Google has even removed this from their accounts.

[Itoldmyselfso]

Passkey comprises of public key that the website you created it on holds, and the private key you store on your pw manager or in the TPM/secure element. As long as you can copy the private key to the new device, you don't need to recreate the whole passkey. In your case, you would just need access to a backup of the Keepass database in case you lose the device.

The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.

[pseudalopex]

People who say users should not be able to export keys are not confused. They believe users should not be able to export keys.

[Itoldmyselfso]

I was referring to confusion experienced by people new to the passkeys creating passkeys for the first time ("Where am I saving this to?", "How do I store this in my password manager?").

[ivlad]

You don’t. You don’t store anything at all.

On registration, a keypair is generated, then the private key is encrypted with the long-term key burned into your security key fob or hardware. The encrypted blob is sent to the server and stored there.

On authentication, after you enter your login, the server sends the encrypted blob and your security key tries to decrypt it with the long-term key it has. If it succeeds, it then request a challenge from the servers, signs it along with the server name and timestamp and sends back to the server. Server validates the signature and if it’s good, log you in.

Expanded: As long you as the user has the security key fob, you can login. You should have 2.

[doodlesdev]

> You don’t. You don’t store anything at all.

Yes, you do.

Whenever a website offers to create a passkey, it could end up in any of these:

- Samsung's Password Manager (if using a Samsung phone)

- Apple's Keychain (if using an iPhone)

- Google Password Manager

- Your operating system's keychain

- A bespoke password manager (e.g., Bitwarden or LastPass)

- Your hardware key

Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.

I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.

[pseudalopex]

dotancohen would not be allowed to store Passkeys private keys in a Keepass database in the case thewebguyd specified. Relying parties would block password managers which allowed this.

[zdp7]

1) Install a keepass client and use it for passkeys.

2) See #1

3) See #1

KeepassXC supports passkeys. They suggest a couple mobile apps that also do.

[samrus]

How easy is it to switch off keepass? And how easy is it to export off whatever you imported to? Passwords are simple, just remember the text. Passkeys have alot of uncertainty around this

[zdp7]

To switch off, just stop using Keepass. If you want want delete the entry on the site. You don't need to, since your Keepass file should be secure and passkeys are designed allow multiple for a site. Passwords are not equal to passkeys and not difficult to add. Everyone seems to think you need to create new passkeys for all your websites. You don't, add them as you go. The hassle of adding it should be less than using a password to login.

[ilchalpenl]

> Let's assume that they were all Passkeys.

Lets assume I put all the effort to explain.

I will give you a better example.

- Lets say you have a google account with pixel phone

- You are using it and added 1000 passkeys

- All are synced to your Google account

- Destroy and Get a new phone. Login to your google account with recovery code.

- All your passkeys are in your phone again.

There are plans in fidoalliance.org to make it portable. Pretty sure you are still not going to move to it.

[sandmn]

It works fine until Google suddenly decides that your new device is not you and asks you to confirm login from previous device...

[account42]

Or until Google decides that you did a wrongthink and bans your account, including locking you out of your old phone.

[ilchalpenl]

See.. the sad thing for doomsayers like you is that if even 1% of users were affected then there would be mass exodus from Gmail. It does not.

Yes, you don't use Gmail so it does not matter. You may be don't know. And often even average Joe some how has a oldphone or iPad that has oldgmail account there or logged into wife's phone or phone based SMS whatever.

it is ok to hate passkeys or google or love only self-hosted but let others do what they want.

I have been user of solokeys (since the first one) - only opensource hardware keys. works for me...

But if you go to the local highstreet then there are tons of people doing this screenrepair etc just to recover the account. Average Joe doesnot mind paying for that. Even will give the repair guy full password to transfer all data from old to new phone.

[ilchalpenl]

Apple's keychain or google password manager - can hold 2000 passkeys easily.

[blochist]

Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?

[ilchalpenl]

Not at the moment. But if you sign into google account in iPhone then you can use Google's passkeys in iPhone.

At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No.

A majority will benefit. End of matter.

A majority don't change platforms (I have not seen them do it).

And lets be honest - even if they were portable are you privacy person that is going to do it? No.

[TeMPOraL]

No, the majority will not. If through some miracles, passkeys gain sudden and wide adoption, there will be a day of reckoning come around the next mobile refreshment cycle, maybe earlier.

People break their phones. That is normal experience. Entirely unsupported by passkeys as they are today.

I'm actually surprised we didn't have more pushback for ubiquitous 2FA, as they have similar threat profile - i.e. addressing the tin-foil threats of cybersecurity aficionados, while entirely ignoring the common threats to real people, in particular the one of broken or lost mobile device.

[coffe2mug]

Incorrect. They break but they fix it.

People break their phones less often compared to telling them keep their keepassdatabase in sync across devices.

Even recently my friend fixed his iPhone XR (10 year old) 3rd party. Everything including passkeys work fine.

[nightski]

No you don't. I use the same passkeys for all my devices sync'd with bitwarden.

[crote]

Exactly. Bitwarden, not the Apple/Google/Microsoft keychain. That's the problem.

[chews]

Dunno why the downvotes, if you're willing to trust Apple or Google this is a good method for passkey usage. because your touchID/faceid/opticalid auth gate the keyring's on either of these vendors your passkey works without having to migrate them. EDIT: Also ANY device that you add to your iCloud has access to the passkeys you've made... it's a dream for secure access.

[dotancohen]

What happens when the user decides to move to an Android device, or even is suspended from Apple for a suspected breach of the terms of service, or Apple decides to not support their country anymore? There are countless reasons to prefer to manage one's own access.

[ilchalpenl]

True... Theoretically correct but in practical sense?

All these doom mongering of suspension happens so rarely that majority don't care.

There are countless reason to DIY. Agree. But passkeys will help the majority.

Also note that the kind of people - like journalists etc - that need to use DIY/local are the ones that are likely to use passkey. Reality.

[ilchalpenl]

Downvotes does not matter. People here that are privacy inclined always find ways to argue about Google or Apple (any major companies). But if you look at their private lives - they adopt tech ASAP. A majority have Apple Pay or Google Pay. Paypal. At the same time use bitwarden also. (And that is fine)

These privacy zealots fail to realise that majority of population does not have time to setup bitwarden server or lineageos or zfs storage etc.

[fugalfervor]

The downvotes are because the commenter did not read or at least did not fully comprehend the meaning of the post they were responding to.

[Petersipoi]

Did you not read the comment thread you're responding to?

[jesseendahl]

> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound

If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.

What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.

The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.

[benlivengood]

> The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.

Another way would be auto-enrolling passkeys from other devices you own through a standard API. Enroll your trusted Apple device in your Google Account's settings, or your Bitwarden/KeePass, and vice-versa. When your iPhone creates a passkey at a site, iCloud notifies Google, which issues a new passkey and sends the public key to iCloud, which auto-enrolls it at the site alongside the iCloud passkey. BitWarden gets the same treatment. When you open your KeePass vault it checks Google and iCloud and picks up any pending offers for passkey enrollment and completes them.

Simple, secure, opt-in, and users control their devices and passkey vaults with minimal hassle. If a device is lost, the other services can help you automatically delete the compromised passkeys and set up your new replacement device.

Matter does something very similar with cross-compatibility between Apple and Google (and the rest of the ecosystem) when new devices get enrolled with the user's choice of PAA; the only thing missing is roughly cross-PAA enrollment but that would be just one additional trivial trust relationship in both ecosystems.

[jesseendahl]

I like it.

The high level UX of this idea feels very compelling to me as a "yes and" -- aka a world where vendors continue to offer end-to-end encrypted syncing within an ecosystem, but then this idea gets layered on to solve the cross-ecosystem problem. I think the trickiest part would be how to do it in a privacy-preserving way, but that's solvable.

[phs318u]

> the only possible way to compete with that UX is to sync the private key across the user’s devices

This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys).

Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.

[Ajedi32]

"A better version of password syncing" is exactly what Passkeys are and ought to be. Just like passwords, but unphishable, unguessable, not reusable across sites, not vulnerable to data breaches, and with better UX.

Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.

[inigyou]

So just a password manager?

[jesseendahl]

Passwords are still significantly less secure than passkeys even when using a password manager.

[inigyou]

Why?

[TeMPOraL]

It's still ignoring one of the main features of passwords for regular people, which is authority delegation via password sharing, aka. "could you please log in to my ${service} and do ${something}, my password is ${password}...".

Yes, that is a feature and a normal use case that has equivalents in meat space, that security aficionados refuse to recognize even exists, much less support.

[lazide]

Not only that, they don’t need to worry if they lose their phone they’re locked out of their accounts too!

[crote]

> at which point it’s no different to password syncing

You still get the phishing resistance, though!

[TeMPOraL]

Is the "phishing resistance" just inability to view and manage your own data? That's a bug, not a feature then.

[coffe2mug]

Downloading and keeping safe local data is a bug for others

[choo-t]

Password managers prevent phishing as they check for the domain name before inputing the password.

[jesseendahl]

Password managers do not architecturally, cryptographically make phishing impossible. Ultimately a user can still be tricked to copy/paste their passwords into fake websites, even when using a password manager. You could blame end-users for this behavior, but attackers don't care about blame. Ultimately, it doesn't matter who's at fault when there are massive phishing attacks happening at scale every single hour of every day. The only real solution to solve this problem for the entire internet is to make credentials architecturally, cryptographically unphishable by design. That's what passkeys give you.

[Someone1234]

Right; but THAT idea is consumer hostile by design.

So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.

[thewebguyd]

> Right; but THAT idea is consumer hostile by design.

No argument from me there, just stating what the design actually calls for.

It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.

But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.

[unscaled]

The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are:

1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO.

2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F.

I might be wrong but at least these are the two parts I know.

And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard.

It doesn't mean they are not confusing, but they are clearly designed with end users in mind.

[marysol5]

Eh, PassKeys are consumer friendly by virtue of allowing the keys to be synced across multiple devices. That actually breaks some of the security of it for the benefit of the end user.

No end user wants to export and store a keychain. So they hand that off to somewhere else.

[packetlost]

> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.

Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.

The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.

[unscaled]

Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.

Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.

What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.

[ivlad]

I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.

[marysol5]

Lest we forget that enterprises have had passwordless auth long before any of this

[michaelt]

> Passkeys are primarily meant to replace passwords

Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.

[packetlost]

> Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

They obviate the need for a user identifier as the key is itself unique, but removing the 2nd factor is a choice of the service, not the designers of the Webauthn standard.

> Also they decided they should be cloud-synchronised

The earlier versions of the spec required that the keys be resident in hardware, but it was updated to allow "roaming" keys. The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud). Most do not.

The usability problems are actually larger than that, see sibling comments for why. Passkeys, even when cloud synced, are still better than cloud synced passwords and still give the option of hardware backed keys for those whose threat model warrants it.

[ivlad]

> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud).

From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.

Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.

[atanasi]

The service may require attestation and verify the actual authenticator metadata.

If the passkey is not accepted by the service, it can use the signaling API to indicate that the passkey was not registered validly.

[packetlost]

Sure, but you can still use a Titan T3 or recent Yubikey model on an iPhone. If I had the threat model to justify it, I would not set up the passkey in Apple's infrastructure.

It is too bad they ignore that though. That's really disappointing.

[account42]

> A particular service can choose to enforce those class of passkeys

And that's exactly why the technology should be rejected while we can. It's no business of a particular service how I use my devices.

[jjav]

> supposed to be device-bound

Device bound is horribly broken idea. Credentials must be me-bound, so I and only me fully own and control the credential. I want to access the site from wherever I want to access it.

[TitaRusell]

This is exactly all the stuff normal people don't care about.

If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.

[sib]

Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.

[thewebguyd]

I mean, no one ever said it was a good design.

But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.

It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.

[BetterThanSober]

Device bound is a bad idea especially if in the future sites is designed to be fail secure, you might be able to recover your account but not your data. The provider will then have to take a negative PR risk for something they cannot do

People lose their device all the time, there's tons of horror story where people got locked out because they lost their sole method of 2FA and if there is a method to bypass that then it is inherently insecure

For the layman yeah it is probably enough

[richstokes]

Device-bound would be a nightmare. I don’t want to have to think about different credential for phone vs. laptop, etc.

[crote]

Easy: it's the token on your physical keyring, right next to your house key and car key.

[Telaneo]

I have 7 house keys and 2 car keys. Getting a new house key is a breeze and cheap, and even if I lose them all, a lock smith can make me whole again. Getting a new car key is a bit more expensive, but also largely not a hassle.

Having spare Yubikeys is more of a hassle than both of those (and more expensive!), and the worst case scenario of losing them all is much more catastrophic. If I have no house key, I still get into my house. If I have no car key, I still get into my car (after a fair bit of hassle). If I have no Yubikey, I have permanently lost access to the accounts it was tied to.

If physical hardware tokens were as cheap as house keys and not much more difficult to set up and copy, then it would be kind of reasonable. As it is, it's unworkable. Even password managers manage to make this work. You can throw your database on every storage device you have and write the master password down on paper, and the chances of you not being able to have access to it are pretty darn close to zero.

[coffe2mug]

No one is forcing you. You can continue to use passwordmanager.

We are talking about the rest the people that want convenience.

In a way that is the reason passkeys synced with Google or Apple just work. No need of hardware keys.

[anticensor]

It's not a nightmare, in fact different sessions of the same user could be used to grant different capability levels across sessions depending on the trust level.

[jknoepfler]

I do not want my identity to be device-bound. I want it to be me-bound.

[thewebguyd]

That's self sovereign identity. But you still need someones that can issue those verifiable credentials, and we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth?

Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information).

Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.

[jknoepfler]

Put yourself in the role of a consumer for a second.

As a consumer, I don't give a shit. I use my driver's license to apply to jobs, my passport to fly, and a password (with 2FA depending on how much I / my employer cares) for everything else. I prefer whatever I use for 2FA to not be device-bound, because that's obnoxious, error-prone and constraining.

As a consumer, I don't see any reason for my auth to be more complicated than that.

[TeMPOraL]

> we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth?

Yes? I mean, that's what literally is there by default in every country. They're not either/or either, they're part of a chain.

Most importantly, none of that is device-bound. Or even person-bound. Which allows for delegation, which is a feature that cybersecurity people keep insisting is not real.

[crote]

How do we verify that you are you? It can't be linked to fingerprints, iris scans, or DNA, as those are trivially leaked, impossible to change, and a privacy nightmare.

Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.

[jimbokun]

Seems like the flow should be:

1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device.

It’s presented to the user as a convenience clearly tied to this device.

…but you still have your text password stored in the password manager’s servers…

[akdev1l]

By still having the password the user can still be attacked via phishing

[thewebguyd]

The user can always be attacked via phishing so long as account recovery methods exist (and they need to exist for obvious reasons). Use passkeys, but so long as you can also log in via password, or SMS code, etc., it's phishable, you can get sim swapped.

Your master password to your cloud PW manager's vault is also phishable (hence why passkeys were ideally device specific, non-exportable).

Its phishing resistant not phishing proof

[akdev1l]

> hence why passkeys were ideally device specific, non-exportable

Not true. The original concept was always for them to be cloud synced.

This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not.

You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”.

> Your master password to your cloud PW manager's vault is also phishable

No, it’s not. You would need to steal my yubikey to get access.

[ivlad]

> Not true. The original concept was always for them to be cloud synced.

It was not. The original U2F spec was created before that idea was around and it talked about hardware security keys as means to store the primary key pair.

[crote]

Yeah, but it's an order-of-magnitude more complicated. It's no longer "click a link and fill in your creds on a legit-looking website", it turns into "hack someone's email, request a password reset, wait the mandatory 24 hours, do a social attack on the provider to pull off a sim swap, and fill in the 2FA code".

> Your master password to your cloud PW manager's vault is also phishable

... which is why all sensible cloud vaults have a separate enrollment key, requiring an explicit action to grant a new device access.

[Lammy]

I don't want my computer to be able to decide I'm not allowed to access something. I'll never use these.

[j0057]

In the Apple ecosystem, passkeys are stored in your iCloud, and access to the passkeys is device bound. So if I generate a passkey on a MacBook, I can then use it from my iPhone as well, because it's encrypted to all my hardware devices.

[phs318u]

Replace the word passkey with password in your comment. What’s the benefit of passkeys again?

If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud?

The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.

[krferriter]

A random website breach can't disclose your password either, assuming you use random high-entropy passwords and the website only stores a hash of it. I haven't really seen the benefit to passkeys over passwords. Pretty much everyone is using a password management service that securely syncs both passwords and passkeys across devices. In that context I don't see the difference.

[thewebguyd]

> Pretty much everyone is using a password management service

In the US, only about 34 to 36% of adults use a password manager. Of the ~64% that don't, an alarming 20% reuse the same password across almost every service, and a ton just rely on browser autofill.

If you use a password manager, you are in the minority. Hell, even if you don't use a PW manager and you at least use a different password for different services, you are ahead of most people.

The general population is largely computer illiterate, and have a staggering lack of basic security hygiene.

[inigyou]

FWIW, browser autofill is a basic password manager.

[coffe2mug]

A random app cannot eat your passkey. Platform authentication ensures more safety. I am not an expert but definitely it does use secure enclave in some ways(maybe decryption).

UX usability is far better. With password and 2FA you have at least 2 steps. Here

Open the app: device like phone or laptop just asks your fingerprint or facial and done.

That is a great benefit for average Joe. Some one trying to scam remotely cannot access the account. The 89 year old grandma will say - I just give fingerprint. Done.

Yes, it won't cover all situations. Like if there is sim swap or bank employee does fraud.

[mwwaters]

The far bigger benefit is phishing resistance (with hardware-contained keys themselves being phishing-proof on a non-compromised system).

It moves to the account recovery flows, but that can be much more difficult to phish.

[inigyou]

Why would a key need to be "hardware-contained" to be difficult to phish? My SSH private key is unphishable and it's right there in a file. It's unphishable because I know there's never ever a reason to send it to someone - in a scenario where that would be needed, I'd generate a new key just for that situation.

[ptman]

Desktop operating systems don't have very good separation between programs. If some malware gets access, it will be looking for e.g. ssh keys and using a keylogger to get the passphrase if you encrypted your ssh keys. Tpm protected passkeys are much better protected

[inigyou]

That attack isn't phishing

[account42]

Good. Device bound keys are a mistake.

[zombot]

> they are supposed to be device-bound

Which in and of itself should already be a super obvious total no-go. Every device will eventually go out of service or will be decommissioned, for a multitude of reasons. Then what, I lose all access, because I went from an iPhone to Android? WTF?

[merb]

Wouldn’t it be better to use envelope encryption and sync the passkeys? I mean with envelope encryption somebody would probably be able to create a rfc that would support cross browser/password manager sync a passkey by using a encrypted envelope that would be able to be deceptively wither via tpm or by using credentials so when syncing it would ask for upn/password of the original device or something so it can even be e2e encrypted, so some kind of federation protocol for password managers that you own

[lazide]

Except I literally never want to have auth tied to a device. That’s ridiculous.