Passkey technology is elegant, but it's most definitely not usable security

https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/

by Flimm • 2 years ago

377 349 2 years ago

freetonik3• 2 years ago

In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.

I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc. I already have a universal solution for credentials: 1password, which is cross-platform. With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer. But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.

Like with many other solutions, the current approach with passkeys is designed for an imaginary "user in vacuum" model each company dreams about, where people are 100% into one ecosystem, forever.

YPPH• 2 years ago

But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs

You can't save your personal passkeys on your work phone and vice versa, but when logging in to a service on one device, you should be able use a passkey from the other device via Bluetooth by scanning a QR code.

freetonik3• 2 years ago

Good to know, thanks! But I might not have the other device on me at all times.

clcaev• 2 years ago

An added challenge: Yubikey NFC doesn't work on iPad, only iPhone. USB operation also seems fraught. This has been so for 7+ years now. If Apple cannot get this to work with a closed ecosystem and the leading vendor, I think the technology is just not ready for mainstream.

_Algernon_2• 2 years ago

In some parallel universe, each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys). Instead of "many cooks" mentioned in the article, there is one standard.

Ignoring site support, this exists. It's called USB and yubikey.

anotherhue• 2 years ago

Was called a SIM card before that.

JumpCrisscross• 2 years ago

this exists. It's called USB and yubikey

An extra physical device is a non-starter for mass adoption.

Too2• 2 years ago

Having a big dongle sticking out of your iPhones lighning port is completely impractical, compared to using the integrated TPM backed storage, unlocked by face-id. Yes there are smaller dongles but only for usb-c and i still don't want to fiddle with it when charging.

It's only a matter of time before desktops gain the same secure key storage as our phones do, add a hardware key to prove physical presence and then yubikeys are obsolete. The only future for yubikeys is for temporary transfer of keys under wrap between devices, where you don't want to use a cloud service for doing so.

While an open api with replaceable internals is a nice idea and one that enabled yubikeys in the first place, once this is integrated in the SoC and the OS, there will be little need for alternative storage backends. What's more pressing now is pluggable synchronization of secrets, for those who don't want their choice of cloud provider to be bound to their choice of OS, or for those who rather synchronize entirely offline through a yubikey.

gchamonlive• 2 years ago

Honest question, this isn't supposed to be a burn in any sense. But isn't it contradictory to want to know how and where your credentials are stored and use any credential management solution that isn't opensource and selfhosteable?

freetonik3• 2 years ago

Fair enough, but I believe there is a spectrum between "I don't want to know things, let them just work" and "self-host and manage an application for storing the most sensitive type of information".

1Password is neither opensource nor self-hostable, and it stores data in the proprietary cloud (at least exports are easy). But I understand that and accept it.

If I get a Macbook, an Android phone, and a Windows PC (a very popular combination of devices, btw), I honestly don't have energy to investigate how to inter-operate their passkey solutions. From the get go, I assume it's gonna be either impossible, or very hacky and fragile. Maybe I'm wrong, but last time I checked I simply walked away thinking "nope, no passkeys for me".

mihaaly• 2 years ago

With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account

And from this account you may be locked out for various reasons anytime, as it happened to countless persons previously, violating exotic or even understandable rules, or just been in the crossfire of some galactic corporate incompetence (some f'd up), but this way you'd be locking yourself out of everything especially if you were that user in the vacuum, exposing yourself to the mercy of a single organization with changing managemenet and incentives as the wind turns in a city's dense downtown.

skybrian4• 2 years ago

I solve this by creating two passkeys for each account, for iOS and Chrome. This covers all the devices I might use to log in and there’s no single point of failure.

mapt2• 2 years ago

At one point, a streamer on Youtube asked his audience something like "Spam F's in chat [to signal that you like this thing I just did]"

Hundreds of users got banned by Youtube for spamming.

But they didn't get banned from "Youtube". They got banned from "Google". They lost access to their Gmail, and to their Android login, and every other Google service, meaning they lost their phone text verification system for every other login, and quite possibly their password manager.

Hundreds of identities were stolen and set on fire by an overly aggressive approach to spam management.

I try to remember this failure mode in planning (or being unable to plan) the security of my online presence.

Then I incorporate Elon Musk's recent behavior and recognize that while the profit motive _generally_ constrains the behavior of these firms, it's by no means assured.

For basic social welfare, either this identity stuff needs to be heavily regulated or all of these big companies need to be broken up.

fishywang2• 2 years ago

exposing yourself to the mercy of a single organization

The nice thing about passkey is that unlike password, you can have multiple per account.

So you can register a passkey from 1password to website A, and also register a passkey from Apple keychain to website A, and also register a passkey from Google account to website A, and also register a passkey from yubikey to website A, so even if you are locked out from one of your accounts, you still have several other ways to log into your account at website A.

And _if_ your, say, Apple keychain is compromised, you can just revoke the passkeys from your Apple keychain from all the websites (yes it's tedious, but it's doable).

paxys• 2 years ago

I already have a universal solution for credentials: 1password, which is cross-platform.

You can store passkeys in 1password so they work everywhere.

NikolaNovak• 2 years ago

The article is 80% about friction and confusion in trying that solution - from confusing prompts and endless questions designed to wrestle control over to local ecosystem, to use cases that just don't work with external vendor as opposed to native platform owner :-(

onetwothreepass3• 2 years ago

But 1password forces you to install the browser extension to do this.

ElFitz• 2 years ago

I don’t know about 1password, but proton pass supports passkeys, on both iOS, Safari & Chrome (and probably others).

freehorse2• 2 years ago

I use proton pass and have the same issues as the author. Whenever macos/ios is in the mood it lets me use it to store passkeys, else it is an endless maze of bugs and confusion. Proton pass supports passkeys but the OS does not always let it communicate with the website.

loloquwowndueo• 2 years ago

Pretty sure 1password can store and use passkeys.

sigzero• 2 years ago

It certainly can.

onetwothreepass3• 2 years ago

It does, but 1password forces you to use the browser extension in order to manage passkeys.

I still don't trust browser extensions. I'm probably being irrational, but it is hard to find good sec info on how "safe" extensions really are.

grahamj3• 2 years ago

I moved away from 1P some time ago due to their move to a subscription model. After trying other solutions and having high hopes for Apple finally shipping a passwords app I finally decided to move back this year.

It's costly but excellent. I have several accounts shared with my wife and was getting caught up in the passkey problems you mentioned. Even though 1P handling OTP is not really 2FA it's very convenient and still more secure than no OTP. I also don't always want to have to have my phone on me.

On top of that I like knowing that if I change my mind at some point I can export my credentials. Moving my iCloud keychain creds was an eye-opener: it felt purposefully painful. You can do it but much of the metadata is missing or lost in the process, with the titles being the URLs. Yuck.

ramon156• 2 years ago

Switching from 1p to icloud makes sense, but there's a decent chunk that isnt in the apple ecosystem. I'm keeping 1p for now, I'd even argue that the price is pretty good, especially for families.

onetwothreepass3• 2 years ago

I prefer to pay for something as important as a password manager. It's like some people get excited about all-you-can-eat sushi: sorry, but raw fish isn't something I want to go super-cheap with.

apitman2• 2 years ago

Have you tried bitwarden?

lxgr22• 2 years ago

Using 1Password as your passkey backend seems like it would solve all the problems you're describing, except that passkeys are (for the time being, at least) locked in to 1Password [1]. It works on multiple OSes (as a native passkey backend on iOS, via browser extensions providing WebAuthN on all major OSes) and isn't tied to your Apple ID.

If you care a lot about exportable passkeys, Bitwarden (and Vaultwarden) can export them. Not sure if any other implementation can import them at the moment, but the data looks portable enough (i.e. it contains the ECDSA private key and all other client properties required).

[1] https://support.1password.com/save-use-passkeys/ mentions that "Passkeys saved in 1Password can’t be exported at this time."

radlad• 2 years ago

1P will support it in a standards-compliant way soon: https://blog.1password.com/fido-alliance-import-export-passk...

KeePassXC also supports export but not yet using the aforementioned standard: https://github.com/keepassxreboot/keepassxc/issues/11363

sheepybloke• 2 years ago

Same, I use bitwarden and it keeps all my passkeys in it and is available on all my devices.

bobbob19212• 2 years ago

I’m not saying I’m against 1pass adding the ability to export passkeys from 1Pass, however, doesn’t this increase the possibility of your computer is compromised (say remote control) and now your passkey is exported / moved to a new device and hacker auths in via that new device? (versus with a hardware passkey which cant be exported electronically)

pcl• 2 years ago

”But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.”

Apple has recently addressed this. You can now create shared groups, and selectively assign passwords and passkeys to the groups. You could easily create a group with your two identities and move the credentials to that group.

https://support.apple.com/guide/iphone/share-passwords-iphe6...

antgiant• 2 years ago

Beware of the hidden catch here. The account that adds the credential to the group “owns” it. So if that account goes away for any reason so does the credential.

mcshicks• 2 years ago

Like this

https://www.congress.gov/bill/118th-congress/senate-bill/884...

efitz2• 2 years ago

I think that we should consider passing a law that a vendor may non disable “log in with” and supporting functionality like password recovery, for a user account for some lengthy period of time after involuntary termination of the user.

But I think that the bigger issue is that I don’t think that large corporations should be allowed to disassociate with their users except in the case where criminal activity against that company is involved. This is especially important now that all the vendors want ecosystem lock-in AND have ToS that allow them to cancel pretty much arbitrarily.

bobbob19212• 2 years ago

Agreed, and some kind of appeals process/ external arbitrator, if your account is terminated due to terms of service or automation.

gwbas1c3• 2 years ago

is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)

Wow, that will immediately become a prime target for hackers / phishers.

CamperBob2• 2 years ago

So?

throw0101d• 2 years ago

I cannot bring myself to agree to any "switch to passkey" prompt from any device because I have no idea (and too tired to figure out) how and where that key will be stored, how do I deal with different devices, etc.

There is a draft standard in the works for export/import:

* https://fidoalliance.org/specifications-credential-exchange-...

joe_the_user• 2 years ago

each computing device manufacturer is required by law to provide a storage so that the user can plug in their single, universal, transferrable set of security credentials (like passkeys)

Indeed and that law would provide overrides for the state. And which state, you might ask? All of them? The state where the device is manufactured? Hmm...

exabrial• 2 years ago

That was called "U2F", but we made it "better" with PassKeys!

crooked-v• 2 years ago

their single, universal, transferrable set of security credentials (like passkeys)

That's an awful idea. Normal people already have a nightmare of a time with getting locked out of accounts, and now you want their entire lives to depend on a single hardware fob that can get lost?

musicale• 2 years ago

With Apple's keychain, and I suspect other companies' solutions, passkeys are connected to your account and at best synced between devices from the same manufacturer.

iCloud Keychain/Passwords works on macOS and Windows, and there are extensions for Chrome and Edge. I don't know whether it works with passkeys though.

But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.

As I understand it, Apple's BYOD support allows you to have a managed/corporate Apple ID and a personal Apple ID on the same device. You can also add a managed Apple ID to a personal device like an iPhone; on iOS (and possibly macOS?) it isolates the data between them so that corporate apps can't access personal data and vice-versa.

I believe it's possible to have multiple accounts with separate Apple IDs, and I think it is possible to add "secondary" Apple IDs to a single account, but I don't have experience with this.

mystified50162• 2 years ago

Passkeys are the ideal identity management solution for spherical users in a vacuum

Mandatum• 2 years ago

But even with Apple, I can't sync stuff between my personal and work computer because they use different Apple IDs, even though the underlying true identity (me) is the same.

By design. This is what caused the ZenDesk, Atlassian, Disney and Sony hacks.

trollbridge4• 2 years ago

Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)

Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.

growse13• 2 years ago

Most passkey stores refuse to let you export them, and the real reason is vendor lockin. (They also did this with TOTP keys.)

Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?

redserk• 2 years ago

If you’re buying and implementing a HSM, you really ought to understand this concept. After all, you’re getting paid to.

I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse.

I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.

fireflash38• 2 years ago

It's both. Most of those vendors have ways to backup those keys securely to same vendor backup product. But they won't let you export them via a wrap or whatever.

It functions both as a security feature and a vendor lock in.

2OEH8eoCRo0• 2 years ago

A YubiKey is not an HSM

croes2• 2 years ago

It’s one of the reasons

eigenspace2• 2 years ago

Import and export of passkeys is coming "soon" to 1Password (as of October): https://blog.1password.com/fido-alliance-import-export-passk...

I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers.

A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.

thugcee• 2 years ago

KeePassXC imports passkeys from Bitwarden: https://github.com/keepassxreboot/keepassxc/pull/11401/files

trollbridge4• 2 years ago

KeePassXC and BitWarden win the award for the only open platforms, then.

(And BitWarden isn’t even “free software”!)

batata_frita• 2 years ago

Vendor Locking-In should be classified as an anti competitive practice.

The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.

criddell• 2 years ago

Don't most sites let you create multiple passkeys which would avoid lockin?

croes2• 2 years ago

Imagine you switch from iOS to Android, now you need to create a new one for every site that need uses passkeys. Not to mention the hassle if you forgot one.

jamesboehmer• 2 years ago

It may partially be because of vendor lock-in, but I think the real reason is security. For example with Apple's Secure Enclave hardware, you give secret-generation responsibility to this chip, and can never see the value. I use it for SSH private keys, which are meant to be disposable/changeable. As much as I want to own and control all my data, I personally think this is pretty good footgun protection, and I'm ok with being unable to export my passkeys from 1password (and for the record, 1password does not prohibit TOTP exports).

trollbridge4• 2 years ago

If the private key is actually stored in an unbeatable enclave, then fine. Apple’s implementation puts them in your iCloud account, which whilst it is overall locked via the Secure Enclave, the passkeys are most certainly not.

I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.

Borealid9• 2 years ago

This is extremely obvious in the new FIDO specification for key export, where they neglect to specify the format in which the private keys are encoded.

In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.

lxgr22• 2 years ago

This really is the least problem.

As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.

comex• 2 years ago

Isn’t that here?

https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#...

The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?

daft_pink2• 2 years ago

I believe they are trying to make a common import/export mechanism to prevent vendor lock in.

cchance2• 2 years ago

I mean... i register in my most common one, and if i cant use that passkey store on another pc like at work... i just ... register another passkey there, you do it once an your done, once at home and once at work,

Groxx4• 2 years ago

Not just "most passkey stores". The spec has nothing about export/sync, so they've been working around it by hand.

There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone.

[1] https://blog.1password.com/fido-alliance-import-export-passk...

Nekit1234007• 2 years ago

One of the Passkeys/WebAuthn spec people made a huge fuss over how KeePassXC did their export function https://github.com/keepassxreboot/keepassxc/issues/10407

jmclnx• 2 years ago

I will never use Face ID or Fingerprint for any device, but I agree, passkeys are a bit too much. Also, the OSs I use may not support passkeys. They are not on the list.

lxgr22• 2 years ago

Your OS doesn't need to support them; browser extensions can implement them too.

Gigachad2• 2 years ago

OSs should add support though because it lets desktop apps auth without having to open a browser login page.

eigenspace2• 2 years ago

While I agree with many of the points raised by the author, I guess I just had much much more pessimistic expectations than they did. If I were to write an article on the topic, I'd probably end up listing the exact same factual information, but with the opposite spin: "This is progressing much quicker and more smooth than I would have anticipated!"

Switching from passwords to passkeys is a big change in the entire security model of the modern user-facing internet. We shouldn't be at all surprised that people are both cautious and opinionated about how it should be done, how to migrate users, and how to deal with fallbacks.

Yes, the current situation is one that is messy and not significantly more secure than the previous status quo, but the direction of travel seems at least promising.

I wouldn't actually want my bank to overnight decide that passkeys are the way to log in, and if I use a passkey there should be no insecure fallback options. I want my bank to roll out a passkey, and figure out the infrastructure around it, probe for problems, and allow fallbacks that are equivalent to their previous systems. Similarly, I wouldn't want every passkey management implementation to instantly coalesce around one specific set of management practices and UX. I want various ideas to be tried out and see what comes out of it, even if some of those experiments are bad.

Schiendelman• 2 years ago

The article you would write is the right article! But it wouldn't get shared and make the first page of HN.

It's entirely possible people have written exactly the article you want, but our discovery mechanisms are all based on aggregate emotional reaction.

growse13• 2 years ago

Lots of criticism in the article, some of it valid, none of it constructive.

Sure, there's UX problems as we're still trying to figure out what good looks like here. But in the absence of specific, concrete suggestions about how we improve usability for unphishable credentials, it seems that passkeys are a pretty good go. Perfect? No. Better than passwords? Undoubtedly.

saagarjha6• 2 years ago

The point of the article is that they are not actually better than passwords in a lot of ways that people actually want them to be better.

growse13• 2 years ago

One of the primary, explicit design goals of webauthn is that they're not phishable. Passwords are phishable.

What are the other ways that people want passkeys to be better?

ghjfrdghibt2• 2 years ago

I don't think it's the responsibility of the author to make any constructive input to the passkey problem. The point of the article is to show the valid shortcomings of this technology that a bunch of companies are attempting to force on users.

My workaround to allow passkeys to be reasonably usable is to use my password manager, just like the author of this article. This makes passkeys essentially the same as passwords.

At no point am I tying account access to a device, or series of devices, as this is ridiculous and unusable.

Passkeys as encouraged by the big companies are all about vendor lock-in than security.

growse13• 2 years ago

I don't think it's the responsibility of the author to make any constructive input to the passkey problem.

Oh, it's not their responsibility, sure. But moaning about the UX without considering the trade-offs and decisions that got us to this point isn't very useful. Passkeys are badly implemented on some sites. So let's fix that.

This makes passkeys essentially the same as passwords.

Passkeys in a password manager are fundamentally different to passwords. Try copying the passkey private key into your clipboard from your password manager.

Passkeys as encouraged by the big companies are all about vendor lock-in than security.

The fact they prevent phishing is just a useful side-effect? This is veering into conspiracy theory territory.

cypherpunks01• 2 years ago

Anyone know what adoption rates for passkey looks like now? I think they are cool too, but the constant prompting to create them and invisible/variable UI everywhere is a problem. It presents as inconsistent as compared with the standardized username/password form that grandmas understand.

eadmund2• 2 years ago

And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS.

I had no idea! That’s pretty awful.

Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform.

I do not want Google to be managing my passkeys or passwords. Even if they promise to keep them device-local, I frankly don’t believe them: the temptation to make it easy for users who have lost a device or forgotten a password is too strong, and at some point they will take the plaintext, and then it is game over as far as security is concerned.

ballenf• 2 years ago

I don't know. If you're in the iOS ecosystem and using iCloud syncing and Safari things are super easy and default more secure than without passkeys. The author's examples of Firefox, chrome, a password manager and a physical key apply to very technical users who seem quite capable of navigating the complexities he complains of.

The vast majority of people are just not going to encounter most of his issues. I sympathize with his issues, but he's kind of complaining that fighting the ecosystem is complicated.

My guess is that <<1% of people use his combination of multiple browsers a non-iCloud pw manager and a physical key on MacOS. And they're not substantially less secure than his setup.

My only issue with passkeys is sites that don't seem to have them figured out yet. They'll let you setup a passkey but then offer to let you sign in with a password first. These seem to be becoming more rare, but even amazon's passkey seems random when it lets me use it. And even then it wants to send me a text message code anyway (this is probably a setting somewhere, so my fault I'm sure).

hkpack• 2 years ago

They'll let you setup a passkey but then offer to let you sign in with a password first.

I am not sure if that is what you're talking about, but the standard way to implement login with passkeys is to use a normal username/password form and leverage the auto-fill mechanism to offer you to sign with a passkey if it is discoverable.

Another way is to have a two-step login, where you enter your login/email in the first step, and then use passkey to login in the next.

There are benefits and drawbacks in both of them.

Also, passkey can be used with multiple authenticators (like Yubikey), and most popular websites consider that verification of the user is not implemented sufficiently for some of them to be used as the only way of authentication, so they don't allow you to login with them without a second factor (i.e. password).

sneak• 2 years ago

It gets worse. U2F keys were stateless, the site key pair was stored by the site (encrypted to, and by, the u2f key). Now, passkeys are stored in the device, and, you guessed it - they have a limited number of slots.

The fido2 situation is really bad.

ttyprintk2• 2 years ago

25 on my YubiKey. Would 100 be enough?

Borealid9• 2 years ago

A Yubikey purchased today actually allows 100 discoverable credentials. Keys running older firmware stored a max of 25.

lxgr22• 2 years ago

Both are awkward in that I could reasonably expect to exceed them in the lifetime of a hardware authenticator.

The ideal number would be infinite and is in fact very achievable with a very small API modification, but alas, the WebAuthN working group didn't consider it necessary: https://github.com/w3c/webauthn/issues/1822

jlokier• 2 years ago

I have about 1000 accounts in my password manager. 100 passkeys to replace them is not enough. I wouldn't feel comfortable with that as a hard limit, if it's to replace all passwords.

Many of those 1000 are obsolete (old accounts I'll never use again), but many are not. At least 30 are things I use every week, most of them financial or tech admin, i.e. not social media. I'm confident (though not certain) that I login to more than 100 accounts over a typical year, and there are accounts that I sometimes login to more than a year since the previous time, glad that I recorded the credential.

WorldMaker8• 2 years ago

Not all passkeys need to be stored on the device. This is exactly what things like key-derivation functions are for. You can have a "primary" device key that derives a Passkey based on the site address with maybe a little salt and/or pepper (but maybe not needed with most KDFs).

FIDO2 allows that just fine, it's a complicated dance between the hardware vendor and the OS right now if your particular hardware device uses a full slot per Passkey or derives the Passkey from some "primary" key.

mongol2• 2 years ago

I haven't used passkeys, I have not been prompted about it, asked to create one, been reminded to change to it, or anything like that. It is like they don't exist to me. Am I supposed to be nagged about it in order to change to it? Or is it something you have to hunt for in the account details of a site? Unsure if I am a late adopter or if the technology has not found me yet.

throwaway894345• 2 years ago

Google, GitHub, and a few other services have bagged me to create passkeys. I haven’t tried hard to understand how to use them, but at some point I created one on one device and whenever I try to log in from a different device it doesn’t work but passwords and MFA work just fine across devices so I mostly just ignore it. Annoying that a lot of services are pushing passkeys as the default mechanism though.

mongol2• 2 years ago

Did you use 2FA before? I use it, possibly they deem my security good enough because of that?

the_clarence• 2 years ago

I moves to an android phone to buy a folding phone and I lost all my passkeys. Its a nightmare

Borealid9• 2 years ago

The article author skirts around the key true observation here, which is that passkeys were a great idea until cloud vendors waged war on hardware keys.

The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.

The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise.

The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware - they want you to use a cloud-hosted passkey instead of using a Discoverable Credential on a Hardware Authenticator, and instead of using a password manager providing its own sync facility. This is shown in the screenshots in the article.

The ideal future state is:

* the provider for newly registered credentials would be a browser setting

* the setting would come configured to use the OS vendor out of the box

* installing a password manager providing passkeys would prompt to change the setting to use the password manager instead

* one of the options in this setting would be "prompt me every time". Approximately nobody would choose that option

* there would never be a prompt for what to use on authenticate() calls, only register(). Authenticate would use whichever valid credential you provided first, whether that's plugging in a token or scanning your thumb to unlock a TPM or whatever

In this world, 99% of people are using OS-vendor-provided cloud-synced passkeys, but technical users get what they want too and everybody has both a secure and an easy experience.

The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor, and they have a conflict of interest because the OS vendors are also cloud services vendors.

fastball2• 2 years ago

What is the benefit to Apple?

neogodless• 2 years ago

Doesn't Apple primarily want the best user experience, and the safest way to use devices? So they should get onboard with what is best for the user.

daft_pink2• 2 years ago

If all your passkeys are synced to Apple, then it makes it really easy to use that new Apple device and really hard to use that PC/Android Phone/Meta VR headset/etc.

They are trying to make an import/export mechanism to prevent vendor lock in, but what if I want to still use my iPhone and my Meta VR headset. Import/export doesn’t mean sync :(

samcat1165• 2 years ago

Every passkey setup flow I've ever seen has allowed me to use a hardware key or the OS provided store. Am I missing something?

Borealid9• 2 years ago

Have you:

A) read the article, paying particular attention to the screenshots therein (ESPECIALLY particularly to the user experience on an Apple device), and

B) noted the part of my comment where I say that I should be able to set the choice of using hardware keys one time instead of needing to do so every time I create a new credential?

Today it's so hard to use a hardware key with Google Play Services that I (a software developer who actually works in this field) have had users tell me their phone didn't let them do it at all. In reality, the support was there, is was just so unusable they didn't even understand they had that option.

berdario• 2 years ago

Some flows might allow only Platform authenticators (disallowing external hardware keys)

https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...

https://www.reddit.com/r/webauthn/comments/197ggm7/comment/k...

The only one that I witnessed, is the optional passkey for restoring your Whatsapp account

lxgr22• 2 years ago

The concept of a passkey as desired by Apple, Google, and Microsoft is that every user magically authenticates using their OS, and has no ability to authenticate otherwise. [...] The reason the UX is confusing is because the OS vendors don't want the users using non-OS software or hardware

Completely untrue. Both iOS/macOS and Android offer an API for third party passkey implementations ("backends"). macOS also offers a client API for that that browsers ("frontends") can hook into. You can use Strongbox (a KeePass implementation) with Chrome, iCloud Keychain with Firefox, a Yubikey with Safari...

It's really as open an ecosystem as it gets at this point, and for software implementations, there isn't even attestation that could allow relying parties to block any specific implementation.

The thing stopping us from getting to that ideal state is that the provider of the FIDO "platform" (the software that lets you choose a key to use) is the OS vendor instead of the browser vendor [...]

No, this "ideal state" is in fact the reality I've been experiencing for the past few months.

Borealid9• 2 years ago

If this is so, could you explain why the dialog for a Google Play Services webauthn login today says "use passkey" (meaning "use google-account-hosted passkey") and "try another way" (meaning "present an options page to let me choose, after another click, a passkey that doesn't happen to be a google one")? How about the bit in the article where the Apple signin screen says "unlock with TouchID" and you have to decline to do that TWICE before you can use a hardware key?

Yes, it's technically possible to use hardware keys today. No, it's not ideal - specifically, what's broken is:

* the user experience where all three major platforms attempt to make it more difficult to use anything other than their platform.

* the ability to sync cloud-hosted passkeys between the major vendors AND self-hosted options

* the ability to decline to use the OS vendor platform once, instead of needing to decline it on EVERY SINGLE SITE, EVERY SINGLE TIME

there isn't even attestation that could allow relying parties to block any specific implementation

This is, unfortunately, not true. FIDO2 credentials have support for an "AAGUID" and a signed attestation certificate that does, in fact, allow blocking particular implementations.

teeray• 2 years ago

It's really as open an ecosystem as it gets at this point

However, they fumbled the introduction by trying the “maximum vendor lock” approach first. Now they need to convince everyone otherwise, even if technically it’s open now.

palata4• 2 years ago

No, this "ideal state" is in fact the reality I've been experiencing for the past few months.

I agree that technically, it seems possible to choose between hardware keys and OS passkey. But I also agree with the article that they try to push their own solution by hiding the alternatives, and that should not be allowed.

mikepurvis• 2 years ago

Looks good until Mallory sets up a phishing site that tricks users into installing a thing that registers itself as their “password manager” and mitms their entire life.

Not saying there aren’t other reasons the OS vendors are pushing back on supplying that hook, but that’s one that is at least vaguely pro-user.

amluto4• 2 years ago

I think a critical feature is missing that makes this almost entirely unworkable: usable handling of backup tokens. There is no way to register a token in a safe. There is no way to name a token to keep track of which one it is. There is no intelligent way to migrate from one token to a new one. Working with two computers with mutually incompatible ports is incredibly annoying.

NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.

Also: the cloud vendor passkeys (Apple, Google, etc) are far more secure against an attacker that steals a device.

This is not to say that cloud based passkeys are amazing. AFAICT there is nothing remotely resembling an automated way to rotate a key. I’m not even convinced it can be done manually in a straightforward manner. This is not so great, given that a passkey is effectively an unlimited lifetime key pair with no revocation mechanism, that may well be stored without hardware security and that can be propagated to different generations of devices. Also, what happens if a device is stolen and compromised at least enough to keep its password manager running?

Borealid9• 2 years ago

NFC tokens have basically no security against a close range attacker. How much this matters depends on the threat model.

No, the CTAP standard (what FIDO is using for communication with NFC tokens) provides pretty good resistance against this threat. There's actually a diffie-helman key exchange between the computer (platform) and authenticator (token). The only way it could really be better is if it did challenge-response for your PIN authentication, but as it is if you eavesdrop a CTAP NFC exchange you do not get the user's PIN, or the ability to generate/use a credential later.

In order to attack a CTAP token over NFC you need to man-in-the-middle it.

Borealid9• 2 years ago

Oh, one more thing!

There is no way to name a token to keep track of which one it is

Tokens support listing which credentials are stored on them, and most (not 100%, but most) tokens also support storing an arbitrary blob of data at least 1024 bytes in size. You can name your token if you want to name your token.

lolinder2• 2 years ago

passkeys were a great idea until cloud vendors waged war on hardware keys.
The concept of a passkey as desired by Yubico was that every user buys a set of hardware keys, uses those instead of passwords, and has no ability to authenticate otherwise.

This was never a great idea, it was totally unworkable for nearly everyone. Physical keys work because locksmiths exist, keys can be copied, and users get to choose when they lock the door/box/whatever. And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.

Hardware keys as envisioned here cannot be copied without registering the copy separately with each and every service, have no equivalent of locksmiths besides "store these 10 recovery codes somewhere safe" (also unworkable as a solution), and between session timeouts and multiple devices users are regularly unable to predict when and where they will need to create a new session.

Hardware keys were designed for a spherical humanity, not for the humanity that has to deal with ADHD, dementia, babies, kids, fires, floods, and a host of other failure modes. OS keys inherit many but not all of the flaws of hardware keys, but at least they don't rely on a human being responsible!

Borealid9• 2 years ago

I think the passkeys would have remained a great idea if all passkeys were provided either by hardware devices not sold by cloud services vendors, or by software not written by OS vendors.

I largely agree with your point, and I don't think most users should be using hardware tokens. But the TPM chip in the user's phone should be usable by any app on that phone, not just by the OS vendor.

I stand by my original statement that the standard was fine until users started getting shoehorned into "use Google passkeys on your Android".

palata4• 2 years ago

And even with those benefits they're rapidly being replaced for a lot of people with PIN codes or mobile apps precisely because physical keys are suboptimal.

I would be careful with the use of "suboptimal" here. PIN codes or mobile apps are possibly more convenient to some people, not necessarily more secure (a PIN can leak, a smartphone can be hacked).

I would argue that hardware keys are optimal in the use-case they solve. It's just that not everybody wants to solve this use-case. And that's okay: passkeys should allow users to choose.

timewizard• 2 years ago

Physical keys work because locksmiths exist,

Physical keys are not a security tool. They are a tamper evidence tool.

have no equivalent of locksmiths

...because there is always someone on the other side of the door who is entitled to change the lock for you.

Hardware keys were designed for a spherical humanity

They were just designed for a world where there is actual customer service. This apprehension on hardware keys seems to be rooted mostly in this fact.

hansvm• 2 years ago

10 recovery codes

Mostly unrelated, I fondly remember Google doing one of those "prove you're you" checks when I was in a different state, allowing me to waste one of my 10 recovery codes as one of the options, and still refusing to let me log back in till I got back on my home WiFi a few weeks later.

WorldMaker8• 2 years ago

installing a password manager providing passkeys would prompt to change the setting to use the password manager instead

iOS supports this today. If a password manager app describes that it implements passkey management, iOS asks what you want to be the default and the UI changes a bit to allow easier choices between iCloud and your password manager app.

It sounds like macOS is the place where Apple is lagging the most on API hooks that applications can use to trigger the UX.

It's also possible that Apple is just prioritizing that macOS users are mostly bought into the iCloud Keychain and their cloud infrastructure whereas iOS does have a large known mixture of iOS/Windows users that may bring their own keychains/password managers.

kenada• 2 years ago

macOS also supports the APIs, but password manager developers don’t seem willing to implement them there.

I’ve used 1Password for a long time, but I’m probably going to drop it for Apple’s password manager because when users ask 1Password to add support, they are directed to use 1Password’s browser extension and universal autofill instead. Neither support passkeys in applications. I also find the browser extension buggy at times (especially with passkeys).

frereubu3• 2 years ago

TOTP suffers from a similar issue - I use 1Password to store my TOTP codes, but both Google and the UK's HMRC tax website talk about using their own apps for codes rather than anything agreed like "one-time passwords". The digital world is rife with this kind of jockeying for position through language. It took me far too long to understand that "podcasts" are just mp3 files from an RSS feed.

Likewise, in the heyday of interactive TV in the early 2000s, when it was going to conquer the world because everyone had a TV but not a computer, an agency I worked for were invited for a demonstration of a choose-your-own-adventure game they were developing. They kept referencing a "carousel system" where all pages were sent in a looping system and when someone made a choice it waited until that page came round in the "carousel". I kept asking whether that was like Teletext - https://en.wikipedia.org/wiki/Teletext - but they absolutely refused to say that and kept saying "well, it's a carousel system".

This refusal to deal in everyday language, alongside trying to get people to use their own apps / sytems, really hinders the adoption of useful technologies.

nashashmi2• 2 years ago

Not sure what you are talking about TOTP suffering from a similar issue.

TOTP works via a secret key provided by the service. The TOTP(secret key + time) function generates a 6 digit code. This is a standard. The secret key can be stored on Authenticators and those authenticators sync to cloud services.

When adding the secret key for the first time to your authenticator, you have to also copy that to a notepad. This way if you want to transfer the keys, you have them available. Authenticator apps don't always allow you to export the keys. TOTP.app is a good auth app that does allow but there is no sync to cloud capability.

frereubu3• 2 years ago

What I mean is that they don't say "Scan this QR code with your time-based one-time password (TOTP) app." They say "scan this QR code with your Google Authenticator app" or "scan this code with the HMRC app", obfuscating the fact that you can scan that code with any app that supports TOTP authentication like 1Password, Bitwarden, Authy etc. All of those prompts should have a link saying "Click here if you're not sure what TOTP apps are" that goes to a page with links to a whole bunch of recognised authenticator apps, where they can show their own if they want to but also show others that people may already use.

samcat1165• 2 years ago

I seem to be in the minority of HN users that love passkeys. I use them for any login that I reasonably can. When creating a passkey I create one in iCloud Keychain as well as in 1Password. I do agree that there needs to be a better import/export story, but I have confidence that will come.

aednichols• 2 years ago

Same. It is annoying to dodge the prompts that guide me to save in Chrome or iCloud instead of 1Password, but with patience I have always succeeded. Of course, I know what I want and when to ignore what the machine suggests, which I wouldn’t expect of non-enthusiasts.

SXX• 2 years ago

I would even get idea to make passkeys non-exportable, but lack of import feature for me as power user just kills passkeys for me.

Gigachad2• 2 years ago

There is a draft spec for transferring keys between password managers. It's complex because they don't want to make it possible to have your passwords dumped insecurely on your computer. But to have them transferred directly between credential stores securely.

jeroenhd4• 2 years ago

Same here. My passkeys are in Bitwarden and they're more complex and secure than any password websites will let me enter.

I don't trust cloud providers like Google and Apple to keep my secrets for me, but with Bitwarden I can just dump the secrets and load them from a backup if I wish to do so.

I've also been pleasantly surprised at how well logging in through CTAP2 works. Any laptop/desktop PC with Bluetooth can use the Bitwarden vault on my phone (after unlocking it with a password, of course) to log in with very little hassle. Much better than copying over passwords, or opening the password vault on every PC I need to log in to something.

Too2• 2 years ago

Smart to have two sets to avoid complete lock in.

fredfoo2• 2 years ago

I think the elephant in the room is the total lack of website/framework/library support Fido has. Trying to implement support on any random site is about as insane as rolling your own crypto and having the single sign on bolt on is sort of how people selling FOSS+enterprise want it.

The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.

WorldMaker8• 2 years ago

Yeah, it has been frustrating me lately that there isn't a simple drop-in Passkeys-only library/framework yet. Right now the best advice is "use Auth0/Okta or competitor and configure them in Passkey-only" which adds a vendor where you shouldn't need a vendor.

The other day I just wanted to store passkeys in Deno KV without feeling like I was rolling my own crypto library. I did not succeed in the limited amount of free time I had on that personal project, and that seemed a shame and a half.

shim__2• 2 years ago

It's rather simple actually: https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent..., no crypto involved

palata4• 2 years ago

Unfortunately, that's probably way too technical for most developers nowadays, who are almost proud of not being able to read a manual.

notatoad5• 2 years ago

on the client side, it seems like it should be simple. in the time i allowed myself, i was not able to figure out how to integrate it server-side in my python app. you're not implementing your own crypto, but you are having to interact with and understnad crypto.

there doesn't seem to be a standard python implementation, and there's no feedback at all about what went wrong if your challenges/responses are not accepted by the client-side APIs. the error if your server-side implementation sends anything unexpected is essentially "no, that's wrong".

fredfoo2• 2 years ago

Yeah right, its easy to write a PAM module too, but configuring an authentication registration and flow is not actually a similar skill set.

cchance2• 2 years ago

Why is it defaulting to passkey if i want to use a security key... probably because 99% of people will be using the builting apple passkey and not a third party hardware device that few have... hence why the hardware device is considered "other"

mixmastamyk3• 2 years ago

It's not merely a default, but a desire to punish outliers to conform.

shreddit• 2 years ago

As an Apple ecosystem user i really like passkeys. I don’t have to remember passwords and once i set up a passkey on a device it’s synced to all my other devices. It’s just really convenient.

EPWN3D• 2 years ago

This piece reads very nitpicky, and I just don't identify with what it's saying. My use of passkeys in Safari on Apple platforms has been basically seamless.

I guess if you use tons of different browsers on tons of different platforms and want to work in hardware tokens, it's a pain, but most people aren't doing that.

The problems highlighted are real, but they don't rise to the level of "Passkeys aren't usable security". For users that would have otherwise not opted into 2FA at all (or don't know how to set up TOTP), passkeys are fine. I'm sure there are some warts to iron out, but they have to be evaluated within the context of the practical alternatives, not the context of the author's own personal security priorities.

wyattblue• 2 years ago

I think you're downplaying real concerns people have. Having two different devices is not an exotic scenario

jbverschoor• 2 years ago

It’s invisible. A black box, non transferable. There’s no mental model that maps and you can’t back it up as a normal person. Implementations are half baked and still require all the rest, all the attack surface is even larger.

Was super excited, totally not anymore.

NelsonMinar2• 2 years ago

I think passkeys are a failed product. Time to give up and start over again.

I don't say this casually. I have been arguing for ending passwords for nearly 20 years now. I'm a software engineer and broadly understand a lot of security protocols. I spent hours understanding passkeys and figuring out how to use them in my environment. The core idea is great! But the usability is garbage.

I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me. All passkeys do now is clutter up the one login flow that works for me (1Password form filling, as awful as that is.)

lxgr22• 2 years ago

All passkeys do now is clutter up the one login flow that works for me

You can always disable that in the settings with one click.

I still can't use passkeys reliably. The combination of bad implementations in Windows, Chrome, 1Password, and various websites has defeated me.

I can't speak for how bad things are on Windows, but my flow on macOS (Firefox) and iOS (Safari) is the following:

- Try to set up a passkey at a site offering them.

- Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites), great, use it in the future!

- If it doesn't work, delete the passkey, make a mental (or actual, in the password manager) note that the site has a broken implementation or very bad user experience, for future shaming in threads such as this. (Hi, Amazon and Paypal!)

Obviously that's not viable for non-technical users, but it does save me a lot of time in the long run, since every subsequent login is so much faster than using whatever second factor sites are requiring me to provide otherwise.

Groxx4• 2 years ago

Log out and attempt to log back in using the passkey. If it works (and it does for 80-90% of all sites)

... and right there is a big part of the reason I distrust the current passkey implementations. That's an absurdly low success rate, and I see similar numbers echoed by many people who use them, regardless of the site's importance to their life or apparent technical ability. (my own dabbling has an even worse success rate, though I've somehow managed to dodge multiple complete-passkey-data-loss issues in clients)

And for some reason it doesn't seem to be getting much more consistently working either.

thefreeman• 2 years ago

As a technical user who understands how these work and has none of the confusion issues the author describes, my biggest problem and the reason I stopped using them for google is they seem to arbitrarily set the session length for passkey authenticated sessions much lower. I found myself needing to reauthenticate with google every day or 2 when signing in via pass key. I assume the developers thought this would be seamless, but it is a very annoying interruption to workflow. Especially since I use 1password as the backend with my laptop screen closed it results in me needing to type my (long and complicated) password manager password every time and usually when I am trying to access something timely like a meeting invitation.

wnevets• 2 years ago

Forcing a new key pair for every single website was a mistake. If the crypto is secure than a single key pair should be suffice. That is how we use public key crypto almost every other use case and we get to avoid vendor lock in completely.

whartung• 2 years ago

Maybe someone can explain it better to me.

It seems that the primary goal for passkeys is to eliminate password fishing.

You still need a password for the site. Even with passkeys, you can still login with a password, either from a different machine, or, if nothing else, to recreate your passkey.

But passkeys offer a bit more security to enforce that you're actually sharing the credential with the proper site, correct?

Am I missing something?

I mean, there's the whole syncing passkeys across stuff, but that's all optional. There's no requirement for that. You should be able to configure multiple passkeys to the same site across your various machines (for whatever reason), right?

And I assume the sites won't "auto login"? Even with a passkey you would need to (potentially) hit a login button or something.

I just want to make sure I understand it clearly.

amelius• 2 years ago

After reading 1/2 of the article, I still have no idea what a passkey is.

mixmastamyk3• 2 years ago

My understanding: It's like a yubikey (a device that lets you login securely) but using a similar protocol without the hardware. "Virtualized" in other words. Unfortunately susceptible to poor self-serving implementation UI by greedy vendors.

alfiopuglisi2• 2 years ago

In my limited understanding, they are similar to SSH public/private key pairs. But the details continue to elude me, no matter how much I read about them. Won't try them out until I get how they work.

lll-o-lll2• 2 years ago

It’s that, except the OS manages the private key (in a “secure enclave”). So you, the user, (or malware), never get access to the private key.

The second crucial part is that these private keys are cloud synced. This means that the average Joe doesn’t lose their passkeys when they lose their phone. Get a new phone, and it will sync your passkeys and you are back. For people in the Apple ecosystem, it really is a straight upgrade over passwords.

Where it sucks:

- I’m not comfortable trusting a big vendor with the keys to my digital life

- I only have one device, so when I lose that device I’m locked out till I get another

- I want to use my own password manager to handle passkeys

- I am in multiple big vendor ecosystems

- I want to export these private keys (this one is sort of coming, the standard has been defined to allow export and import, but again in such a way that the user (or malware) cannot access these private keys)

growse13• 2 years ago

A passkey is a resident webauthn credential.

samgranieri• 2 years ago

I'd like to just keep using security keys, thank you very much. They are much simpler and easier to understand and explain.

ilaksh• 2 years ago

I like the idea of using a password manager, but I think we should be aware that can create a single point of failure. For example, the LastPass breaches.

NelsonMinar2• 2 years ago

This article links to a bunch of pages at FIDO Alliance, the official passkey info source, pages like https://fidoalliance.org/fido2/

FIDO Alliance's website is pure garbage.

On first load all the content is covered by a demand you "sign up for updates!", a modal blocking the rest of the page. Also there's a surveillance consent popup that opts you in to tracking.

It takes 9.9MB to load this content-free page. Closing the distractions so you can read the content loads another 3MB.

Why would I trust this alliance for anything to do with website creation?

jmakov• 2 years ago

How is this different than just using your SSH key?

mixmastamyk3• 2 years ago

One difference is that it is hardcoded to the destination site.

vinay_ys• 2 years ago

The most common lock and key ergonomics that everyone is familiar with is the following:

1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.

2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another. And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!

3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.

4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.

5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!

6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.

7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.

8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.

-----

Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!

tasuki• 2 years ago

chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account

I have never used passkeys and don't know much about them, but isn't the main point that they're distinct per device?

If one syncs pass keys using a password manager, what benefit do they bring over passwords?

Groxx4• 2 years ago

The main benefit: if used to replace passwords, they eliminate bad passwords and password reuse and password leaks by things you log into. Which is a gigantic improvement in practice, as those are extremely common ways for mass account theft.

(I am not personally a fan of passkeys for a variety of reasons, but the main goal is very pragmatic and something like passkeys is a very obvious choice. I just don't like this spec, the UX awfulness and railroad-everyone-into-giga-corp-systems-and-giving-up-all-control shown in this article is a direct and very predictable result of the spec's decisions.)

---

Per-device is an option (part of the spec, and I believe always allowed), but it has a bootstrapping problem that leads to custom out-of-spec shenanigans (how do you attach your account to a second device, without any other way to log in, if the new device has nothing that can prove it's related to the other?) and most people don't have enough devices to be able to have guaranteed backups. Lose your phone and you might lose literally everything. Or a house fire. Data is FAR easier and cheaper to put in multiple locations for redundancy.

Also I set up new devices like a dozen times a year, whether it's a new physical device (relatively rare) or simply an erase and start over / OS switch (at least annually , it ensures my backups work and I get rid of cruft). If my passwords weren't backed up and handled with far more paranoia than my browser session, I've have lost them at least a couple times.

Arnavion2• 2 years ago

They don't bring any user-visible benefit over passwords if you use a password manager for your password (so that the password is stored securely on disk behind the password manager's login) *and* the password is unique and large (eg randomly-generated by the password manager) *and* you have the password manager autofill it instead of copy-pasting it manually (because the password manager can reliably check the domain name without falling for lookalikes, homoglyphs, etc).

From a UX perspective, passkeys eliminate user choice about the above matters, so it's easier to railroad users into secure-by-default.

From a technical perspective, a shared secret like a password is generally worse than an asymmetric key like a passkey, especially since stupid websites can save the password directly instead of using a KDF in the usual way and then get breached, but if the secret is unique that matters less.

sunshowers3• 2 years ago

It is possible to use distinct passkeys per device, but that's a crappy user experience, similar to having a distinct SSH private key per device (which is also often recommended by naive technologists). You generally want to lean towards turning M * N problems into M + N problems.

gwbas1c3• 2 years ago

The best way to solve a big problem is to break it up into lots of tiny problems.

It seems like, IMO, the best way to get the general public to adopt passkeys, and to refine (cough debug cough) the UI, is to use them in low-stakes situations, in a gradual rollout.

Instead of focusing on high-stakes use cases, like banking, perhaps:

1: Focus on low-stakes situations, like blogs and news sites

2: Services need easy ways to "add a device," such as opening a link in an email or SMS on the device they want to use.

3: Don't bother syncing passkeys across "devices." Instead, focus on syncing within the browser, where passkeys sync however bookmarks sync.

4: Work on APIs for a user to elect to use a 3rd party passkey manager

At that point, services like iCloud, OneDrive, Google Drive, ect, could also provide passkey synchronization. It's up to elect to use such services; because otherwise, re-signing-in on each device the user uses might be "good enough."

tonymet• 2 years ago

Every additional factor just weakens the chain. None of these solutions addresses the social attacks due to decreased usability. Users are more confused and have less control now. They will spam every factor to get to their resources.

notatoad5• 2 years ago

regular people strongly disagree. from what i can tell, people who aren't HN commentators or tech bloggers love passkeys.

you click "sign in" and you are signed in. that's the dream. my non-technical family and friends have been lamenting not being able to do that for years. my customers are asking for it.

hbn• 2 years ago

Give it a few more years to marinate, and people start getting new devices. Then we'll see how good this actually works.

gavinhoward• 2 years ago

And that will quickly reverse once people start losing their accounts by losing passkeys or devices.

My extended family fought me about migrating to Signal for years. I stopped trying. One or two years later, they were all on it, acting as if they hadn't given me grief for it.

They have learned their lesson, though. A couple of them have come to me asking about passkeys, and I tell them the threat of losing access and let them make their decision. I think both of them chose to keep passwords.

Groxx4• 2 years ago

Every person I've talked to in person who has used passkeys has lost all their passkeys at least once, by no fault of their own.

The more techno-masochistic ones tried again immediately out of curiosity (hence "at least"), but the rest have sworn off passkeys permanently.

And I don't blame them. Without cross-platform sync being standard and literally everywhere, it's trusting hardware and OS vendors to do a good job and inter-operate correctly for the long-term future. They've all used computers for long enough to know that's not something you can trust them with, particularly not in low-margin devices like most people use.

notatoad5• 2 years ago

i think you're overestimating how good people are about maintaing their passwords. if you tell people "you'll lose your passkey and have to reset it" they'll freak out. but most people lose their passwords and get locked out of their account on a somewhat regular basis anyways. people suck at passwords.

if they can have that level of reliability with a bit more everyday convenience, they'll be happy.

benced• 2 years ago

I'm really not convinced by passkeys as a socio-technical phenomenon because it seems to lock people to their OS. As a technical user, having them in 1Password which is OS-neutral (and plans to support export eventually - I'll change my mind on passkeys if this never comes), they're great.

rawgabbit2• 2 years ago

I guess I am a bit dense when I create Apple passkeys for the few websites that support it, I don’t have any issues with using chrome or safari and macOS or windows? I will test again but I don’t remember experiencing this.

lll-o-lll2• 2 years ago

I think there is a big difference in experiences for people who are in the Apple ecosystem and people who aren’t. Apple has made the whole show seamless, so you move from device to device and everything just works, your passkeys are there. At worst, you use your phone to do the login.

It’s also seamless if you lose a device. Your new device has your passkeys, and you can get by with an iPad or older phone until replaced. I think the space where people have all the pain is outside of this ecosystem. Apple is showing it can be done well, but it’s clearly not the experience people are having outside of that walled garden.

cratermoon• 2 years ago

"Most try to funnel you into a vendor's sync passkey option"

Therein lies the problem. Every vendor's profit motive and #enshittification means they want to own your passkey and all the personal data associated with it. None of the care to interop or work with decentralized solutions. They need your data, and they'll do everything they can to lock you into their jail.

high_5• 2 years ago

Passkeys deployment reminds me of a cartel agreement among FAANG without the actual coordination. It's too good of a new tech frontier not to colonize.

dp-hackernews• 2 years ago

Why not use something similar to SQRL instead?

https://en.m.wikipedia.org/wiki/SQRL

commandersaki4• 2 years ago

This is from the guy that created a new, unnecessary, cryptographic primitive by chaining multiple invocations of scrypt instead of modifying the parameters/rounds of scrypt.

paultopia• 2 years ago

This matches my experience perfectly. As someone who is technically skilled but has no particular security expertise, I've tried to gradually implement passkeys where available across the most important and frequently used of my accounts, and... I'd have to go read the goddamn spec to have any idea what's going on. Pretty much all I've learned is that sometimes I can use touch ID to log into stuff now, and sometimes I can't, and the reasons are totally damn opaque.

greatgib• 2 years ago

The magic of password is that you can write them to paper or keep them in your mind. No interoperability issue if suddenly having to use it temporarily or permanently with another device, like if you lose your phone. And you can also pretend they don't exist and no one can prove otherwise. Also if you don't use a password manager, no one (hacker or else) can extract it from your head like it can be forced from your devices.

jeroenhd4• 2 years ago

That password is Hello123! for most people and that's why people get “hacked”. Great that you're one of the dozen or so people who can keep hundreds of passwords in your memory palace for several decades, but that's not feasible for us mortals.

Good passwords are hard because password booklets get lost, or aren't nearby when accounts are created, and people are terrible at remembering hundreds of passwords. Or even ten passwords, as I've found out working helpdesk.

If everyone used passwords safely, we wouldn't need 2FA on all that many services. Unfortunately, credential stuffing remains super effective.

I'm not saying passkeys are the perfect solution here, but pretending passwords are fine as-is is just burying your head into the sand.

Calamityjanitor• 2 years ago

Realistically passwords can also be forced from your head using 'enhanced interrogation techniques'.

gsibble• 2 years ago

I agree with many of the downsides but the only devices I use are Apple. Macs, iPhone, iPad. For me, passkeys are universally simple.

Sorry other OSes and browsers other than Safari, which I switched to specifically for passkeys and Apple Pay, aren't as elegant.

That's Apple's advantage. Their hardware and software ecosystem.

And that's why I never look at anything else.

godelski• 2 years ago

I recently switched from Android to iPhone (and had to get a second iPhone because in <2 weeks I got more scratches on my screen than I have on my multiple droid devices used for 5 years...).

I learned a lot about 2FA from that experience... not in a fun way. The problem really comes down to this: let me register >1 devices for authentication! Luckily Google does this but many places don't. So you're kinda fucked if you exchange your device and don't convert everything first. Interfaces are crazy bad. Firefox is a good example: go to manage account, scroll down to "Two-step authentication" and you'll see "Enabled" with an option to "Disable" or "Get new codes". But I registered this into Ente!

Even FIDO keys say you should buy tap two. One to lock in a safe (they should make this easier by allowing some way to clone a key). Why can't I register 2 devices or multiple methods. More so, why can't I set some priority leveling like prefer security key, email if OTP is used, require message to fall back to email OTP.

This isn't just a problem with passkeys, this is a security problem in general. I really don't think there's enough thought put into how things happen in the real world. I'm pretty techy so got my issues solved but if it were my parents? Well they would swear at me for having implemented that security and never trust me again, falling back to much lower security. It's hard to blame them.

So does anyone know the real way to solve these issues? We're on Hacker News. Yes, the best security is if you lose a key you lose access, but this doesn't work for the real world and for most people. You shouldn't be at risk of losing an account if you lose or destroy your phone. We should also have solutions that don't require internet or reliance on big tech 3rd parties that get Metadata as is the case with single signons. Yes, provide that option, but there's got to be a better way (that can also permeate into standard practices!!!)

__MatrixMan__• 2 years ago

I'll be avoiding them until I'm sure that the attestation object is not being used as a nefarious back channel between the vendor of my authenticating device and the service that wants to authenticate.

The way the protocol is set up now feels like a slippery slope towards a world where I can't be sure that my new accounts aren't actually containing information about whether I had been to a protest recently or whether, at the time of sign-up, my biometrics indicated that I was in an altered state and likely to be easier to fool than usual.

dilippkumar• 2 years ago

I wasted an inordinate amount of time trying to fight Apple Vision Pro to get it to read my Yubikey.

I failed. My apple vision pro was rendered useless because of a single passkey.

Dumbest tech ever.

franga2000• 2 years ago

Passkeys are simply over-engineered. A passwordless login system need only the following:

- $AUTHENTICATOR is one of (browser extension, browser, OS, hardware) - $AUTHENTICATOR stores mappings ($SITE,$PUBKEY) => $PRIVKEY - $SITE can ask $AUTHENTICATOR to generate a new $PRIVKEY and give it its $PUBKEY - $SITE can ask $AUTHENTICATOR to sign a challenge with the $PRIVKEY corresponding to one of the $PUBKEYs for that $SITE - the user can pick which $PRIVKEYs are synced and which can be exported (depending on $AUTHENTICATOR capabilities)

Bonus points for adding a way to do the authentication off-device through QR codes, so $AUTHENTICATOR one one device can authenticate a session on another device (like using a phone to log into $SITE on the desktop, perhaps for the purpose of adding another authenticator there).

commandersaki4• 2 years ago

Fully agree. I'd say the overengineering is to support competing vendor interests and introducing crap like attestations. Though, I believe some extra engineering is needed for the constrained resources on a hardware token authenticator.

mystified50162• 2 years ago

I'm so unimpressed with passkeys. It's just like blockchain, trying to solve a poorly defined social and legal problem with pie in the sky 'elegance' and overly complex technological solutions.

I don't think cryptography is the way to solve phishing. I mean sure it can, clearly. Bitcoin also works as a currency, but it hasn't stopped people scamming and stealing money.

If you're a person wondering if you need passkeys: you need a password manager instead. If you learn some basic safety habits and always trust your password manager, you get almost all the benefits of passkeys with almost none of the downsides.

Passwords— if used responsibly— are fine for 99.9% of what anyone wants or needs. To be responsible with passwords, you just let the computer do it. That's really the problem passkeys solve, just in the most typically obnoxious way.

IYasha• 2 years ago

How about every site and service let me use my username+password combination and stop bothering me with 2-3-4-5FA bullshit? I can manage my own passwords, thank you!

Passkey technology is elegant, but it's most definitely not usable security

Related Stories