hackernews client

Passkeys are not a trap

I do appreciate that passkey adoption has led to wider support for hardware security tokens for sites where I actually care about increased security over password managers, however.

5 days ago

Yeah, a lot of websites these days seem to block or mess up autofill where I actually want it: I can’t say how many websites break credit card autocomplete, TOTP code autocomplete (e.g. via Apple’s native TOTP implementation), username/password autocomplete. I can never really tell if it’s incompetence or a misguided idea of security, but it’s extremely annoying.

thayne

5 days ago

This would be true if websites consistently annotated inputs correctly, but they don't. So password managers are left to guess what input is the username, which is the password, etc. and they don't always get it right.

nh2

5 days ago

> for a tech-stupid person

> password doesn't show up you know there's a problem

Here is your contradiction.

The normal person will just assume that some tech isn't working today again.

A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.

Brian_K_White

5 days ago

"it guarantees to the site owner that the user cannot be phished"

Well gee how nice for the site owner.

Problem is my priorities are my absolute ability to never lose my most critical assets through some means outside my control, not the site's convenience.

It was ok to use imperfect systems back in the days when the bank and the store and even the government all had a desk a mile away you could go to in person and get anything cleared up and override all possible "usually it works like this" with your physical presense an drivers licence and birth certificate or simply 5 people who all attest they know you.

We no longer have that ultimate backup plan, so really F anyone's attempt to justify basically tricking people into doing something unwise that puts them at actually greater risk because their life is less under their own control, and doing this under the very banner of claiming to care about the users safety!

It's freaking amazing.

trinsic2

5 days ago

This is the rub for me. Passkeys are really about protecting the site and not the user. Its really designed backwards IMHO.

Dylan16807

5 days ago

I don't know if they'd even be aware of how to copy the password out of the manager...

Your point about multiple passkeys is valid though. That affects me too. I use multiple hardware keys but cannot enroll many sites because of this.

nine_k

5 days ago

> that syncs them across all of a user's devices

What's the point of a passkey that can technically be exfiltrated off a device it was created on? I thought the whole premise of passkeys is that they can't be copied, and hence can be trusted as much as the device access control. Am I missing something?

xp84

5 days ago

It would introduce a different usability problem to have them remain truly stuck on a device, like, locked inside a Secure Enclave. Mainly that you’d have to do the setup again for every website, on every device. Buy a new phone? Back to the Stone Age. Authenticate with a password to each site on the new device, find the “add passkey” place, and install it.

I think that is a big step down from the convenience and friction level that the native password managers get you, where you save your password once and for the rest of your life, as long as you maintain fealty to Apple/Google/Microsoft, your password will always be there in autofill.

spiderice

5 days ago

I think you're missing the article that made it to the top of HN a few days ago that explained all the many different varieties of PassKeys

https://news.ycombinator.com/item?id=50048312

zdp7

5 days ago

Passkeys are always more secure.

scarab92

5 days ago

Password managers provide all the same security benefits as passkeys, without the lock in.

peanut-walrus

wink

4 days ago

The thing the people are also sometimes missing is that I leave my YubiKey at home... especially in those situatiosn where I am prone to lose it.

Going to a concert - I'll take my phone but not my YubiKey, etc.pp

And if I enroll 2 YubiKeys, I can deposit one safely at home. I want my phone to be less important, not more important.

doc_ick

5 days ago

[dead]

alwillis

5 days ago

From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.

"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].

You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.

On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.

I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.

Here's a video of an export from 1Password to the Passwords app on an iPhone [2].

[1]: https://support.apple.com/guide/iphone/passwords-devices-iph...

[2]: https://youtube.com/shorts/gJ8BzT73JzY?si=zSY8vp_v297IfCro

tempest_

5 days ago

I don't fear loosing all my devices in a freak boating accident. I fear apple deciding they don't like me for whatever reason and then I am fucked.

It is why I never use "sign in with <google, meta, apple, whatever>"

faust201

5 days ago

True... but a majority don't care. And it works.

As always you are not compelled to that. Lets others enjoy the convenience of passkey.

g8oz

5 days ago

But what I don't understand is how are passkeys improving what Apple provides here. You could have just done this with passwords and had all the ecosystem benefits you outlined.

jms703

5 days ago

You can't enter a passkey at the wrong website.

makeitdouble

5 days ago

You still need a password to exist, so while the passkey won't activate the user can still leak the account's credentials.

To cover that gap, you get rid of passwords altogether, and now users lose access if the passkey fails to sync or isn't available on one of their devices (let's say a Kindle Fire tablet)

Passkeys being bound to the domain is neat, but not without tradeoffs and practical workarounds. At least that can't be the only aspect to look at when making a choice.

eglintondust

5 days ago

My password manager won't do that either

wildzzz

5 days ago

Sometimes the url for the login page changes or I'm logging into a different part of the site and my password manager doesn't recognize it. My university used Duo for authentication but depending on which resource you were trying to access, the subdomain might be different. How would I immediately know that I had just typed in my credentials to a misspelled domain or a hacked user account on a school web server displaying a phishing login? That last one would be even more nefarious because my browser might not even display past xyz.abc.edu/ and it would even have a valid SSL cert. Even if my password manager didn't recognize that URL and I manually typed it in, my passkey manager certainly wouldn't even attempt sending a key.

ThunderSizzle

5 days ago

The real problem is that companies/institutions should procure one domain name, and stick with it. There's no reasons so need to be redirected through 6 domain names when signing into Microsoft, all of which look like a phishing attempt URL.

One domain, one account.

stavros

5 days ago

It's not physically impossible to enter a password in the wrong website, though, which bites lots of people who get phished.

5 days ago

For security? If you're not using a password manager, that means you're using the same password for almost every site. Which means every site is a point of failure for every other. This means some way of generating and saving random passwords for each site (i.e. a password manager) is absolutely required for security. You are welcome to use the password manager that comes bundled with the device you paid for (apple, android), or use paid cross-platform ones like 1password (which works well), or use free cross-platform ones (in which case you might get what you paid for).

jmbwell

5 days ago

5 days ago

5 days ago

If that's so then what actual security benefit is derived from it?

Of course the sites presumably will flip the switch at some dreaded point in the future where you can no longer circumvent them, but at this rate it may take a long time to reach a use by majority of users.

Ostrogoth

4 days ago

This. I use passkeys on mobile os to more quickly access commonly used services, but they do not completely replace other passcode+2fa credentials.

qingcharles

4 days ago

On XMoney I can't access the app on my desktop because it forced me to use an iOS device to set up the account, and I guess, but don't remember it mentioning, that it created a passkey on there. There is no alternate way to log in. You're just permanently locked out. I spoke to the devs, they say that's intentional.

ylk

5 days ago

ethbr1

5 days ago

Exactly. I'm disinclined to cut Apple, Google, and MS the benefit of doubt for steering a standards committee to spec + real world usage that privileges themselves.

zdp7

5 days ago

It's not though. Passkeys are meant to allow you to have multiple. They also don't need to replace passwords. Take my bank setup. I have a password, a windows passkey and an android passkey. I saved the time needed to setup the passkeys, the very first time I used them. The passkeys are easier to use, than my password, and more secure.

ylk

5 days ago

you can see in both the lastpassword and the bitwarden tutorials that the default iOS password manager can be toggled on or off, just like the other options.

ylk

5 days ago

you're misunderstanding: this isn't specific to passkeys, this is for changing the password manager(s) used when filling passwords, 2fa codes and passkeys.

since the person I responded to couldn't find it, I linked tutorials. it amounts to opening the Settings app, going to "General" and then "AutoFill & Passwords", so it's also not terribly difficult to find compared to other iOS settings.

you could've at least tried to understand what's being talked about before blindly complaining.

taikahessu

5 days ago

Whenever LostPass, I mean LastPass is mentioned, it makes me feel twitchy and reminds me of that time I made a really bad tech decision of using it.

LastPass is not a secure place to store your passwords. Bitwarden is the second worst place. Don't just take my word for it, do your own research.

happyopossum

5 days ago

5 days ago

Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account. A year or so ago, a site I relied on started enforcing biometric passkey enrollment. Without thinking about it I logged into the site on my phone and enrolled there, but unfortunately (a) that meant it didn't get registered as an "other device" in the internal system, and (b) the site didn't work correctly on mobile devices (legacy system). So logging in on a desktop would then demand that I activate the passkey, but of course the passkey was on the phone. No way to access it, and the site didn't offer me the QR code / bluetooth method. I don't remember exactly why, but it just didn't work - probably had something to do with it not liking Firefox on Linux or something.

And to add insult to injury, it wasn't even a single factor login the way passkey advocates promise. The site still demanded a normal password to log in! It was actually 3 factor authentication; something I know (the password), something I have (the passkey), something I am (the biometric).

This wasn't some random website that didn't matter made by nobodies. It was a US government website for managing grant money.

mooreds

5 days ago

> Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account.

We rolled out passkeys a couple of years ago (I work for an auth/CIAM provider). This was before most passkeys were synced (which gives me the heebie jeebies--that's a valuable set of private keys to be shipping around).

We built passkeys to be an alternate login method, not a primary one, for that exact reason.

WorldMaker

5 days ago

Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.

My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.

(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)

> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows

It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).

Terr_

5 days ago

> Supporting multiple passkeys should be a minimum requirement for every Passkey implementation.

To go a step further, "multiple minimum" should be like... 5+. Enough to cover several devices (Laptop, Phone, Desktop) then at least one for backup/disaster-recovery purposes, and some wiggle-room for when replacing an old device with a new one.

Terr_

5 days ago

P.S.: Though to re-echo the cynical refrain from the prior "is a trap" other piece [0], "Yet still Netflix does not want you to share your passkeys." In other words, services like them have a (bad, unreasonable) incentive to try keep that number down.

[0] https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...

WorldMaker

4 days ago

I went to authenticate through Okta on my work phone. It prompted me for the passkey. Since mobile passkeys didn't exist, I got stonewalled. I had to make a blood sacrifice just to get Okta to allow password access again.

prepend

5 days ago

This is why I don’t like passkeys. I’m surprised the “use site from multiple devices” use case isn’t more common.

Am I nuts for accessing a site from both my mobile phone as well as from the multiple computers I use?

This also gets super messy when combined with multi-site auth services like id.me where I need to use the same login to access very diverse sites and services from multiple computers (eg, irs.gov, treasurydirect.gov, disburser.treasury.gov).

Terr_

5 days ago

[dead]

regularfry

5 days ago

The trap is the ratchet towards attested hardware and closed-source-only implementations.

Glyptodon

5 days ago

5 days ago

The threat models here are often very similar to existing Password Manager threat models. If an attacker gets access to your Password Manager they get access to every password you have stored there and can do what they like with that information. The same applies to your Passkey Manager, which in many cases (including for your own peace of mind) is/should be the same app/vault as your Password Manager for other types of passwords.

A lot of the same Password Manager requirements and best practices apply to Passkey Management such as using strong master passwords or biometric unlocks or device PINs. Using Password Managers that support device bound hardware security enclaves, etc.

But even more so than average Password Management, because Passkeys are public key infrastructure the benefits you get out of the box exceed those of ordinary passwords. One of the factors in most Passkey implementations here is that sites (defined by hostname) all get different public keys. (Users are suggested to use different passwords for every site, but are not required to. Passkeys do that technically and are generally enforced in that effort by browsers and Operating Systems.) Leaking those public keys is no longer an issue (they truly are public keys), and leaked public keys aren't generally useful to other sites and apps. (Passwords that leak and even sometimes salted and hashed passwords that leak are liabilities and can be useful for rainbow table attacks or social engineering attacks or password reuse attacks.)

There are certainly edge cases to Passkey Management but in general the threat models follow Password Management threats: does someone have physical access to your device? Do they have access to your biometrics or device PINs?

But also the blast radius is reduced compared to usual Password Management threats: a single leaked private key generally only impacts a single website/app. Being able to sign a Passkey challenge once doesn't mean unlimited access (a password can be used forever after finding it), because challenges have timestamps and random entropy and generally don't support replay at all.

jasomill

5 days ago

5 days ago

This is site-specific, but typically by using the same mechanisms used to reset forgotten passwords.

Also, sites can and often do support multiple passkeys, which opens up the possibility of allowing for reliable account recovery using one or more backup devices (one or more YubiKeys, for instance) that is still siginificantly more secure than reset flows using SMS or email.

ThunderSizzle

5 days ago

I think the point is I can make a physical copy of my backup email and password. How do I print a passkey for safekeeping?

In other words, my email can be signed in from anywhere on purpose. It's a feature. The chances of me forgetting my password is zero, because I can back it up 7 way to Sunday.

A passkey seems to miss these basic accessibility issues. For a random website, that's fine, but for the service all of websites use to auth me, access is more important than locking it down to one device.

cocoto

5 days ago

Most Passkeys use PQ PKI algorithms. From statistics I've seen most are Elliptic Curve on currently recommended PQ curves.

comex

5 days ago

You don’t have to use a password manager that relies on an account. Personally I use Strongbox on iOS and macOS, which stores everything (including passkeys) in a .kdbx file. I then sync the .kdbx file over iCloud, but if I lost access to iCloud then there would still be copies of the file on all my devices. Overall this is not as secure as the more centralized alternatives, but it does leave me in control.

So I'm not sure how I'm supposed to log in with the passkey, there's no QR code or anything.

Gigachad

5 days ago

It's part of the OS. The browser calls the API and macos or windows will show the QR code to scan. In theory Linux will get this in the future but I suspect like most things it will take a while.

d3Xt3r

5 days ago

I'm using Edge and Windows 26H2, and logging in via a Microsoft authentication system. There is no QR code.

This is why passkey are a failure, no one knows how they work, and even one someone claims they know, the reality is often different.

Gigachad

4 days ago

5 days ago

> Many people read that and say, "see, that's why I'm never going to use passkeys! I'm safer managing my own backups, and I'm too smart to be tricked into copying and pasting my password to the wrong site." But they're wrong. You are not too smart to be tricked. Nobody is.

It is not remotely difficult to not fall for phishing attacks. I think I've seen one in my entire life which was actually well crafted such that a person might fall for it even if he was paying attention. One. Everything else is the lowest effort slop where all you need to do is hover over the link to see "this does not in fact go to microsoft.com like it claims".

smw

5 days ago

The overwhelming evidence is that this isn't true for the majority of users.

antonvs

5 days ago

You’re saying the majority of users have fallen for phishing attacks? That seems like selection bias. Since you only see reports about successful phishing attacks and don’t see any reports about all the people who log in safely and successfully every day, you assume a “majority of users” must fall victim to this.

ishouldnotbutk8

4 days ago

It's actually the other way around - everyone likes to read about clever APT attacks, or zero day exploits, or impressive supply chain attacks. But despite what you may read, phishing attacks are the most important.

Consider: most (over 50%) of company compromises starts with phishing (or with reuse of compromised passwords, which are also usually sourced from phishing). It's even higher for ransomware attacks specifically btw. This means that if we were able to stop phishing and credential theft, we would cut number of cyberattacks by half! That's not something you can downplay.

antonvs

4 days ago

Sure. It's still nowhere near the case that a "majority of users" fall for phishing attacks.

dzdt

>They have to be transmitted.

Everyone knows to hash passwords now and browsers basically enforce SSL. This is not a practical differentiator.

>Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.

They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).

>If your entire database is stolen, it’s useless.

As are databases containing strong randomly generated password hashes. What is your threat model here, they somehow forgot to hash their passwords yet they are still hashing session tokens, storing customer data in completely separate databases, safely storing private keys, etc.? It requires quite the strawman scenario to apply.

OneDeuxTriSeiGo

5 days ago

> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).

This is only technically true because of the definition of what a passkey is is vague.

Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.

When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.

So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.

This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.

nemomarx

5 days ago

Can I do hardware attestation across several devices yet? My desktop, my phone, a console, my girlfriends phone of a different brand if I need to log into a shared account, etc?

It seems like one of those things that only works if you're sticking to one ecosystem.

OneDeuxTriSeiGo

5 days ago

Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.

ThunderSizzle

Stealing passwords is already an incredibly rare attack nowadays. The attack is almost always on the cred reset path. Suppose a user loses their phone with the secure enclave and wants to login to your site using their laptop without a secure enclave.

Are you really going to block that cred reset on the grounds that it's a downgrade? You're going to have a lot of users calling your support asking why they can't login after switching devices.

So you allow it, then oops it was not a laptop, it was a phishing site.

OneDeuxTriSeiGo

5 days ago

That's not the argument being made.

The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.

So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.

Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.

Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.

Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.

TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.

aeternum

5 days ago

The phishing site will say something like "Your passkey is out of date, click here to create a new one" I call that cred reset since it is similar to password reset, perhaps some sites support multiple passkeys, in that case the phishing site will use the register new passkey path instead of reset existing.

Phishing sites already frequently target the reset/create-new-password path because it's actually easier to get a user to generate a new password vs. trick their password manager. Plus 2FA is usually required anyway since no 'remember me' cookie is avail so a password reset is equal in difficulty to a password login.

That method still works just fine with passkeys right?

The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks. Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.

OneDeuxTriSeiGo

4 days ago

> That method still works just fine with passkeys right?

Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.

If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.

> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.

Yep and passkeys explicitly exist to eliminate this behavior.

> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.

Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.

Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.

TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.

5 days ago

Anyone not hashing passwords is going to find a way to mess up passkeys.

WorldMaker

5 days ago

How? Public keys are public keys. They are designed for full disclosure. They are "leak proof" in the sense that leaks should not ever matter. The useful thing about public key infrastructure is that it asymmetrically moves the security threat to managing the private key, which is in the user's hands, and away from the public key. With a strong password I have to assume that both my Password Manager is up to the task of not leaking it and that the remote website handles my password correctly (including salting and hashing and not leaking and not using a hash algorithm with known collision flaws and not using a hash algorithm with large well known rainbow tables, etc…). With a passkey I mostly only have to worry that my Password Manager is up to the task, those are the threat models I get to worry about, I no longer have to worry about if a remote website is keeping pace in the ongoing arms race because all they have is a public key that I don't care if it leaks.

jambalaya8

4 days ago

Going to be pedantic, and suggest you are always safer with nobody having your public keys that have no legitimate reason to do so. Is it dangerous in and of itself? Is it very likely to cause you a breach? No. But does it in some way expand the attack footprint, however theoretically? Yes. At least in the age of AI.

cowlevel

5 days ago

Here's one way to screw it up: make the public key the password. Normally only the user and the site know the user's public key for a given site, so it's as secure as a password, and nobody notices the problem.

WorldMaker

4 days ago

I don't know how you could screw that up and not break the UX flow in a way that would have some sort of noticeable hiccup, given the Webauthn API as it has been standardized. The response to a Passkey challenge includes only a short fingerprint or "unique name" of the public key, not the full public key. Off the top of my head I think you only see the full public key in registration steps, and then if you try to re-register a key most Passkey implementations are going to enroll an entirely different key.

I'm sure that there are big enough fools out there, I'm just thinking there might be signs they are doing something wrong in that case.

aleksejs

5 days ago

> re-enroll attacker's key or register attacker's passkey

Can you walk me through how that would work?

autoexec

5 days ago

Probably something like this https://cybersecuritynews.com/hackers-abuse-microsoft-entra-...

aleksejs

5 days ago

The article describes a straightforward phishing attack that works specifically against accounts that are _not_ protected by passkeys:

> Depending on which multi factor method the account uses, the victim sees a matching fake screen, whether a one time code prompt, an authenticator app number match, or an SMS page.

The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails. When a phishing campaign with the subject line "Your Mailbox is Full, Log In to Fix Now!" succeeds, that does not demonstrate an interesting vulnerability inherent to your mail server's mailbox size limits.

autoexec

5 days ago

> The only sense in which passkeys have anything to do with this at all is that the attackers used the word "passkey" in their emails.

That's wrong. They attackers actually go on to create a real passkey that gives their device access to the compromised account.

Accounts that are already protected by passkeys can still be vulnerable too. see:

https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...

https://www.esentire.com/blog/securing-passkeys-thwarting-au...

https://unit42.paloaltonetworks.com/passwordless-authenticat...

aleksejs

5 days ago

Right, if you phish the credentials to an account that is not protected by a passkey, one thing you can now do is set up your own passkey on it. That's exactly what passkeys would've protected the victim against!

The other articles you've linked also describe attacks against accounts that allow non-passkey logins, or attacks that require a compromised browser.

5 days ago

5 days ago

You're arguing theory and not practice. In theory they're better of course. The problem is the implementation. And implementation is a mess because everyone is trying to lock you into their own little ecosystem.

nathanaldensr

5 days ago

Exactly! Whereas passwords are extremely flexible and can be stored, managed, and written down in numerous ways that are vendor-independent. Want to store your passwords on sticky notes in a safe? Go ahead! Want to use Bitwarden? Yep, you can. KeePass for offline storage? Yes! With good password hygiene (128-bit entropy, never reusing passwords) there is virtually no risk, especially with 2FA added.

piaste

5 days ago

You can (and should) do the same with passkeys. Like SSH keys, they're just text.

Save a passkey in Bitwarden, then export your vault as JSON. You'll see a nice plain text JSON block with your passkey that you can print, or backup, or import into whatever replaces Bitwarden.

MBCook

5 days ago

In implementation, passwords are a complete disaster. We’ve been dealing with the fallout of it for decades.

In theory, if everyone did everything correctly and followed best practices, passwords would work quite well.

Reality shows we are not anywhere near there.

Someone1234

5 days ago

> There is nothing to prevent you from entering your super secure u quiet password on the wrong site if you get phished.

You replied to someone talking about password managers, which objectively do exactly that.

> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.

And Passkeys don't offer portability, user choice, or user control.

Cryptography may be a solution, passkeys are one technical implementation that at is core is designed around smartphone-first, vendor-first, brand-loyality-first thinking.

john_strinlai

5 days ago

>which objectively do exactly that

password managers do not do that. open up your password manager, press "copy" on the password, and then paste it into a random website. it will paste it.

(i think 1password just recently enabled an option that will warn you if the website is different than the one it has, but it still lets you paste it)

Someone1234

5 days ago

So they do, in fact, do that and you have a workaround? They won't autofill on a phishing site, thus the copy/paste bypass.

It is a pretty big red-flag.

MBCook

5 days ago

Autofill is not the same as use.

You can not use a passkey on the wrong site. Period. They’re unphishable.

Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.

That’s absolutely not true with a password manager. They may TRY to prevent you from ACCIDENTALLY entering it on a website, but they don’t stop you.

Telaneo

5 days ago

> Short of somehow talking a user through finding the full private key and getting them to send that to you, there is no way to trick a user into giving you what you need to get into a website impersonating them.

So you're telling me they're phishable?

john_strinlai

5 days ago

>They won't autofill on a phishing site,

right. and in an office setting, bob in accounting will go "weird, autofill isnt working, ill copy/paste it".

5 days ago

> Passkeys don't offer portability, user choice, or user control.

This is objectively false. Every major platform provides user choice in Passkey Manager. It's the same flow/settings to setting up a third party Password Manager.

All of the ecosystems have defaults that include some amount of portability: iOS defaults to Passkeys synced through iCloud Password Manager and backed up/restored with device backups. Android defaults to Passkeys synced through Chrome Password Manager. Windows defaults to Passkeys synced through Edge Password Manager. All of the ecosystems have plugin systems to support third party Password/Passkey Managers such as 1Password or Bitwarden.

Most devices that support Passkeys support a QR code bootstrapped flow for cross-device/cross-ecosystem Passkey challenge signing via Bluetooth LE.

Most ecosystems deliberately don't provide explicit private import/export to help protect users, but that's more an implementation detail than a technical requirement, and mostly not an implementation detail for "lock in" reasons but for simple security reasons: the private key you cannot export is the private key that is harder to steal by bad actors. The private key that you cannot manually import is the private key that can't be installed by bad actors.

necovek

5 days ago

You lose a device or the local DB that keeps your passkey and you are screwed.

You need to migrate from one login domain to another (rebranding, change of login providers...) and none of your customer credentials will carry over.

Your password might not be stored anywhere except in your head.

Your local storage gets compromised and your passkeys are there for the taking (password in your head isn't).

"Cloud" password managers who hold your passkey private key part is exactly like them having your password and are worse than websites having proper cryptographic hash of your password: they might not be e2e encrypting it (you were comparing with sites doing password hashing wrong too), so a breach exposes all your passkeys just the same.

My point is that there is no panacea. Passkeys are like SSH keys for the web. I still put a passphrase on my SSH keys. Do you?

autoexec

5 days ago

Passkeys can be, and have been, stolen and hijacked. They make it more difficult for scammers and hackers to get into your accounts, but not impossible. How many phishing emails have you personally fallen for that this is your #1 concern over the fragility and complexity of passkeys?

5 days ago

> Passkeys can be, and have been, stolen and hijacked.

Proof needed.

> How many phishing emails h

The point is the average Joe will not be phished - especially important stuff - like email or eBay or bank. That is the reason for passkey.

Yes, many people in HN can avoid scammers.

autoexec

5 days ago

Feel free to google for more:

https://www.forbes.com/sites/zakdoffman/2025/08/28/yes-your-...

https://www.howtogeek.com/passkeys-were-supposed-to-be-more-...

https://www.malwarebytes.com/blog/news/2026/08/googles-synch...

https://cybernews.com/security/google-passkeys-vulnerability...

https://cybersecuritynews.com/passkeys-via-aitm-phishing-att...

https://www.zdnet.com/article/your-passkeys-could-be-vulnera...

coffe2mug

4 days ago

[dead]

classified

5 days ago

Nothing of this explains anything, at best it increases the confusion. If anything, all this mumbo jumbo pushes me further away from using passkeys than before.

john_strinlai

5 days ago

the non-mumbo-jumbo version is:

- you can't get phished

- you dont need to worry if your password is securely stored

classified

5 days ago

And what if I need to use a different device?

WorldMaker

5 days ago

- Your Passkey Manager generally offers some form of multi-device sync. Most Passkey Managers are the same as Password Managers so it may even be a multi-device sync you are already used to.

- Devices support a flow where a QR Code kicks off a Bluetooth LE handshake between two devices to sign a one time Passkey challenge. That can be used for one time login on devices you don't sync your Password Manager to or to help bootstrap additional Passkeys on the new device.

john_strinlai

5 days ago

my passkeys are in 1password, and accessible from any device i have 1password installed on. it's a very smooth experience (both adding new ones and using existing ones).

classified

4 days ago

Thanks, that actually makes me rethink my decision not to use passkeys! Enough for a test run anyway.

MBCook

5 days ago

The secure part of a passkey does not have to be transmitted. It’s public key cryptography. It’s used to sign something as proof that you control the key.

And for that reason, the server does not have the secret. It only has the public key, which is useless on its own. So it can be stored in the database in plain text unencrypted. And you’re not really taking any risk.

Passwords are not cryptography. People may use cryptography to store them at rest, or their hash. But the true password still has to be transmitted. The first time, and every time.

undersuit

5 days ago

>But the true password still has to be transmitted. The first time, and every time.

The password never has to be transferred. In fact never having the password should be the goal. Not even a first time. Don't let the password leave their device. You transmit the hash.

piaste

5 days ago

That just means the hash is effectively the real password. If an attacker gets a hold of the hash that you transmitted, they can use that to authenticate to the server.

All that you gain by transmitting the hash, is that the attacker will need to modify the client's request to inject the stolen hash.

If the client (website or app) runs on the attacker's own devices, this is trivial. I suppose it is a valid obstacle if we are talking about an ATM or similar locked-down client.

undersuit

5 days ago

Don't store the hash the client sent you. Hash the hash on the server side.

lll-o-lll

4 days ago

Which makes the hash the password and the hash of the hash the hash. You achieved nothing. If you truely don’t want to send the password, there are of course ways. But it’s a heck of a lot more complicated than this and no one is doing any of it because… Passkeys is what you end up with.

thaumasiotes

5 days ago

> Bull. People need to stop repeating this.

Wow, you sound like you know what you're talking about.

> They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.

Ok, you've stopped sounding like you know what you're talking about.

Passwords have to be transmitted or stored. They don't have to be transmitted and stored. As you note, we usually opt for transmission but not storage. You could do it the other way around.

> There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.

> Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.

They can still be entered. Not working isn't the same thing as not being sent. A cryptographic exchange should hopefully fail before anyone who's pretending to be the counterparty you want learns enough to impersonate you. But you can enter anything anywhere.

> Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.

Unique strong passwords offer the following:

1(a). They are never transmitted (well, once), and provide phishing resistance; or

1(b). They are never stored, and provide leak resistance.

2. In the event of compromise, no other credentials of yours are simultaneously compromised.

It's true that it would be nice to enjoy phishing resistance and leak resistance.

Here are some other things unique strong passwords offer:

3. You are free to establish any relationship you like, with anyone you like. You don't need permission from Yubico to create an account somewhere.

4. Yubico can't pretend to be you.

You might notice that passkeys don't offer any of those. Your comment appears to enthusiastically endorse the idea that passkeys are a trap.

> Passwords are fundamentally broken. They cannot be fixed.

This is the "PGP is fundamentally broken" argument again. It will never be valid.

If you ask any followup questions, the reason that "PGP is fundamentally broken" is that people use Outlook plugins, and those plugins mean that they're constantly sending email in plaintext when they should have sent it encrypted. There's a very, very simple solution to this.

Don't use Outlook plugins. Run PGP yourself.

Before you send your email, check whether it looks more like "OK, everyone's ready for the kidnapping on Thursday" or "Eb+h+Q1iDEYUgJlO5GTtmcibC+D1E9oJWvZeoy9I2tpqxe9j/iokAx0R". You will be able to tell the difference. Nobody has ever failed at telling these apart.

If you were about to send the email, but it's still in plaintext, don't send it.

Passwords are no more fundamentally broken than PGP is.

Maskawanian

5 days ago

What are you talking about? Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

The way passkeys are being pushed is so clearly an attempt to add friction to leaving walled gardens. Stop talking in absolutes in a world of greys.

linkregister

5 days ago

That's not accurate. If that were true, then a hacker stealing password hashes would enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.

Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.

Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.

undersuit

5 days ago

>then a hacker stealing password hashes would enable them to instantly log in, without cracking them

How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.

linkregister

5 days ago

> How do you know the hashed value stored in the database is the same hashed value the user submitted?

Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.

undersuit

5 days ago

There is a comparison.

Ra8

5 days ago

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Unless I'm misunderstanding what you're doing, this achieves nothing.

Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.

Maskawanian

5 days ago

Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.

If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.

If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).

MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.

Ra8

5 days ago

What if the hash you're sending is discovered? I can use that to login to the service; it offers the same protection as a plain text password.

Maskawanian

5 days ago

As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.

aeonik

5 days ago

The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.

I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.

Here is my hashed password. Good luck:

    $argon2id$v=19$m=65536,t=3,p=1$YTE4NzBkMDIwMjRhMGY5NzU4OTc2ZWY5YzI0N2RjOTY$GSBlUwWxr4BBs+5o5Ye2NphT9PFeWx4ECG6siED9uVQ

You can't use that to login to my system. You can only use it to validate if I give you my password...

MBCook

5 days ago

Correct. The hash effectively is the password at that point.

If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.

bayindirh

5 days ago

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.

Many sites have e-mailed my password in the open when I registered, as well.

I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.

piaste

5 days ago

I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.

Barbing

5 days ago

4 days ago

This would work, but the first stage hash is effectively the password at this point.

    Client:
        C = SHA256(password)
    
    Server:
        V = Argon2id(C, server_salt)
    
    Database:
        stores V and server_salt

undersuit

4 days ago

Good I still don't want to know the password. If the first stage hash is compromised there are bigger issues, bigger than even if the database of hashes or passwords got hacked.

mlfreeman

5 days ago

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Don't assume everyone coding a login page is as competent as you though...sadly.

aeonik

5 days ago

The mechanism proposed by the GP is not competence. It's a well-known vulnerability called "pass the hash".

encom

5 days ago

grayfaced

5 days ago

Yep, just look at the FBI alert of signal accounts being hacked. This is the same "vulnerability" that syncing passkey will have.

Users don't use good passwords or even password managers. Users reuse passwords.

user

5 days ago

[deleted]

7bit

5 days ago

They offer protection against credential theft. Duh.

mattbee

5 days ago

My thoughts exactly.

Anything that randomly makes a Windows 8-style popup offer to keep my login credentials safe makes me want to run farrrrr away.

The vibe of the original criticism, even with its technical flaws was this: are passkeys - as a standard, and a user interface - vulnerable to corporate capture? I think passkey defenders are focusing far more on the theoretical technical superiority, and ignoring how instinctively alarming the average implementation is.

We face a lot a lot of attempts to capture our data, and passkey feels like a new frontier.

For me, I know exactly where I am with my password manager & TOTP. I think the current confusing interface of passkeys will make me less secure rather than more, so I've not invested the time to think about how to use them.

bkdbkd

5 days ago

Agreed. They put someone else between you and your access, between you and your security.

Lets give the guys at the Home Depot all the keys to our super secure house locks. Any time you want to get in, just roll down to one of 5 convenient locations, authenticate with the HD, and they will issue you a one time entrance pass to the house. Easy.

Bullshit.

blackcatsec

5 days ago

Definitely not wrong here. It is a confusing mess for most people. Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience. Everyone else? not so much.

gumby271

5 days ago

I think this is exactly the "Passkeys are a trap" argument though right? If you lock yourself into a single vendor, everything is easy and beautiful. If you choose a diverse set of vendors, it sucks so much more than passwords and password managers ever did.

willis936

5 days ago

4 days ago

"They". Again, it was one guy, who didn't have the full backing of his employer much "the FIDO group". Who made a suggestion, though it was written as a threat because he was bad at communication.

Not to mention the only way to blacklist a specific app from Passkeys is to use the AAGUID from attestation which means it only applies to attestation. A few pieces of software were providing AAGUIDs by choice even when not attested and Apple helped remind them that the spec says non-attested Passkeys should always just return an Empty UUID (all zeroes) in AAGUID. The people that are going to block non-attested Passkeys might as well block all of them, including Apple consumer Passkeys.

warkdarrior

5 days ago

> Keepassxc and strongbox passkey integrations

Isn't that a single vendor (or two)? How is this not lock-in?

Banditoz

5 days ago

KeepassXC at least allows you to export your passkeys should you choose. The people behind passkeys do not like this. https://github.com/keepassxreboot/keepassxc/issues/10407

ylk

5 days ago

This is not accurate. The very first sentence of that issue is:

> Passkeys should never be allowed to be exported in clear text.

and from another comment by the issue creator:

> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.

They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.

Banditoz

5 days ago

The kdbx format is encrypted on-disk. You need a password to decrypt the database.

dwaite

5 days ago

That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.

alterom

3 days ago

>That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.

Such security, very rules, wow.

Because an ZIP file with the encrypted key and the password to it in plain text is sooooo much more secure (but it doesn't break the rules, right?).

dwaite

5 days ago

Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.

The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.

timmyc123

5 days ago

Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".

Banditoz

5 days ago

keepassxreboot/keepassxc#10407

  [Passkeys] should never be exported in clear text
  Overview
  Passkeys should never be allowed to be exported in clear text.
  [...]

I suppose we have different interpretations of the headline.

timmyc123

5 days ago

maybe read the whole issue?

willis936

5 days ago

I use nextcloud to sync my own keepass database across my devices. Both nextcloud and keepassxc are open source.

Please explain how self hosting open source software is locking me into a vendor.

If the sky falls and strongbox ceases working with mac/iOS I can use android and linux. Nobody is locking my lockbox.

Gander5739

5 days ago

Well, KeePass is self-hosted, and I hadn't heard of strongbox before, but it says on the website:

> Store your data anywhere you like, online or offline. Sync with every major cloud storage provider or your own server over WebDAV or SFTP. Use your Strongbox database with any KeePass compatible client on any platform.

watermelon0

5 days ago

5 days ago

My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.

fg137

5 days ago

But can you use Apple Password app on an Android device?

iAMkenough

5 days ago

If that's the argument, it's bull. If you use Apple hardware, you're not locked in and required to use Apple's default Passwords manager.

5 days ago

I’m not saying built your own mobile OS.

5 days ago

As a Bitwarden (and Vaultwarden) user on Mac/iOS/Safari, Linux/Firefox and Android I have had zero issues with passkeys since I started using them a few years ago.

The first two accounts I switched over to passkeys were my Nintendo and Playstation Accounts as it made sign-in much smoother.

I now use passkeys pretty much everywhere I have the option (at least on high value accounts such as Amazon) and I have not once had an issue. Not having to use a TOTP (or worse an SMS or email based one use code/link!) is much nicer in my personal opinion.

Some sites have a much better designed on-boarding process than others I 100% agree there. I find the sites that do a poor job with their passkey enrolment are the same sites that also did a terrible job of 2FA/MFA setup as well though.

5 days ago

>Thankfully, for folks all in on the Apple ecosystem, it should be pretty decent of an experience.

How many people are for now and forever more all in on the Apple ecosystem. You never have to login on another non Apple device ever?

Telaneo

5 days ago

This describes most non-techy people I know who are 20~ years older than me (unless they're 40+ years older than me and only using a laptop to check their email).

rootusrootus

5 days ago

Step away from HN, and there are probably a lot of people who only use their phone to access the Internet. Smartphone brand loyalty seems to be strong, too.

croes

5 days ago

But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me

alwillis

5 days ago

> But you can’t simply switch to Android without recreating every single passkey. Sounds like vendor lock-in to me

Not so fast. Migrating passkeys from iOS to Android is possible now; migrating from Android to iOS is still being worked on.

Ricky Mondello's team at Apple created the Passwords app which brought passkeys to iOS, macOS, etc.

The entire presentation is worth watching if you’re interested in passkeys; the the clip below starts at 24:00 mark where they talk about migrating between platforms.

    Starting with iOS 26.5, you can choose to move passkeys and passwords
    from Apple Passwords to Google Password Manager. However, Android still
    needed "a future update" to receive them. That same update is meant to
    add transfers from Android back to iPhone [1].

The FIDO Alliance created a specification in 2024 called Credential Exchange Format [2] for moving credentials including passkeys, between passkey managers on the same device and across platforms.

In other words, being able to move passkeys between devices and platforms has always been part of the plan.

[1]: https://youtu.be/yVadD-Lfrfk?t=1454

[2]: https://fidoalliance.org/specs/cx/cxf-v1.0-ps-errata-2026030...

Onavo

5 days ago

Well designed platforms and auth frameworks allow adding multiple passkeys. The problem is this requirement was never coded into the passkey standard.

al_borland

5 days ago

5 days ago

Same. Fully agreed.

New and interesting ways to get locked out of your system.

kmfrk

5 days ago

So far, I've had a hard time setting up an iCloud passkey on desktop Windows. Windows Hello keeps intercepting most attempts at a passkey, and 1Password will usually step in otherwise. The UX around it continues to be baffling to me.

At least there's a dedicated migration protocol for passkeys, but I'm not super stoked about how basic Apple's password management is, and how few fields there are for each profile.

But I also feel like it's time to retire my YubiKeys ...

LoganDark

5 days ago

You act as if the experience on Windows is the point of Apple's password manager. I'm not surprised the experience is pretty bad -- as far as I can tell, accessing the passwords and notes is pretty much the only thing you can really do on Windows, and the user experience is significantly impaired compared to Apple devices.

(For example, it only stores the passwords in memory and never persists them locally in any form, because there's no way to secure that, so it has to redownload them from scratch every time you open the app. It also only supports proper Windows Hello PINs rather than normal account passwords, because that's the only way to get proper hardware backed cryptography locked behind authentication, etc. It's a mess)

bayindirh

5 days ago

5 days ago

Does the passkey still serve a purpose in this scenario? Why not log them in by email and set a very long lived cookie so they don't have to log in often?

Gigachad

5 days ago

In my example reset by email has only been activated as a disaster recovery scenario where the site has lost it's domain. Under normal circumstances you would not enable it.

qurren

5 days ago

They give me OpenID vibes, and non-tech people can't understand what they are.

Heck, as an engineer even I don't get them. What ever happened to password + yubikey?

blltprfmnk

5 days ago

Still amazed that on HN of all places people are confused by or having problems with passkeys. I have yet to see any of the issues people are guesstimating could become problems and adopted on day one.

I have had two poor experiences, where passkeys I set up at one point stopped working and I had to generate a replacement, but this was not a problem because I have yet to come across a site that didn’t continue to offer other means of logins.

I don’t see anybody complaining about the login-via-emailed-link which seems to be the much more common trend these days and which I really dislike because it introduces an unwanted delay in login (and I have come across many sites for which this is the only means of logging in).

fatnoah

4 days ago

> but I do know as a user that they appear to be a confusing mess.

I'm a very tech savvy person, and understanding the ins and outs of passkeys has been a time investment, and that's the problem. Technical and security merits notwithstanding, they're a confusing mess. I understand how they work, but what I don't really understand, is how to recover when they don't work.

Selfishly, I end up being tech support for my extended family, and I don't have the stamina to try to explain to them how this works.

dwaite

5 days ago

5 days ago

In best practices for SSH keys you should be using different keys on every device and shouldn't be extracting/copying them. Best practices are also to use different keys for every SSH host in addition to per-device keys.

Passkeys enforcing keys not be extracted/copyed as plaintext and that keys are per-host/domain are just following ancient SSH best practices.

Because yes the SSH world is sloppy with dangerous plaintext (or modest password encrypted) key copying and reuse. That does make it a "simpler" ecosystem, but that doesn't make it a better ecosystem.

That said, Passkeys generally are frequently copied, most of the ecosystems support multi-device sync and backup. They just aren't done in a way that provide plaintext export if you want to print a book of your Passkeys and store it in a safe deposit box or sloppily `scp` them from one machine to another.

sandmn

4 days ago

I think KeypassXC already provides plain text export and Bitwarden provides some export as well. I guess eventually either passkey ecosystem will become locked to a few specific vendors that won't implement functionality FIDO does not like or passkeys will be extractable. In first case it'll become vendor locked corporate standard, in second - same as passwords with url verification.

Or it can stay a niche standard most people don't care much about, we'll see.

WorldMaker

4 days ago

I think it's only technical users and paranoid users that care about export. Non-technical users are fine with device auto-sync and Cloud backup/restore, which is what they get today out of the box from the most common Password Managers.

We are in the era where the average non-technical user doesn't even necessarily know what a file even is, they are used to apps managing everything with Cloud sync and "just working".

Export can be handy for "offline" backup, but in practice the thing to backup offline is the device PIN or Password Manager "master password". Especially because in practice you aren't using just one Passkey, you are using hundreds or thousands. (One per host/domain/app, at least.)

> implement functionality FIDO does not like

The KeypassXC GitHub issue wasn't "FIDO", it was one guy acting like he could make threats on behalf of FIDO, without even the full backing of his employer, much less other members of FIDO. It was bad communication to write a suggestion in the form of a threat and pretending to speak for others.

jeroenhd

5 days ago

jmbwell

5 days ago

So in my own experience, the same tool I use for TOTP is the one I use for passkeys, suggesting it’s at least possible for passkeys to be as frictionless as TOTP.

On the rare occasion I’m logging into a device that isn’t mine, that doesn’t have my password manager on it, scanning a QR code from a device that does have my password manager on it has been enough to get me in. Without sharing any secrets with the foreign device, incidentally

So I’d wager your concerns are valid and are likely to be addressed over time, as this stuff develops rapidly. It might even be better in your scenarios already

Lately it has been a tap-tap operation to enroll a passkey. Sweetwater.com surprised me with it the other day. I was done in seconds, and now I can log in without even having to enter a code. Face ID handles it for both iCloud Keychain and Bitwarden

CyberBlaed

4 days ago

Add to my frustrations the many domains of places that don’t share a passkey. (I kinda understand it but not fully)

Amazon.com, UK, DE, JP, all need different passkeys. Yet my password and TOTP works across them all seamlessly.

And then some pass managers will only store ONE passkey for that login/password.

Its mighty frustrating and while I have been told and see the biometrics make it more secure…

It’s a pain in the arse to now have a stack of domains each in my password manager when searching.

:( In security, you forgo SO MUCH convenience.

baud147258

4 days ago

I've been working on passkey-adjacent systems recently (including systems integrating the physical passkeys developed by a team in the same open-space) and I don't feel like the passkey industry has answers to that, in terms of ease of use/usability. Right now I'd say between an OTP on a phone and physical passkey is that it might just be quicker to plug in the passkey and push the button (if applicable) than fishing my phone out of my jacket, unlocking it, launching the app and typing the code...

Cort3z

5 days ago

I’m not necessarily a security expert, but my understanding is that passkeys are better in two (or more?) fundamental ways.

- it is linked to a domain, as the article states, which makes it less likely to “exposed” in phishing attempts - it is a challenge system, essentially a public private key system, so the private key never leaves your device. Kind of like tls/https. Which means that even if bearer/login token is lost, your “password”(private key) isn’t lost. - also, an obvious bonus is that you get a really long “password” which is practically impossible to guess

Sorry if any of my terminology is wrong here.

charcircuit

5 days ago

>What happens when I go to the same site on a different platform?

Scan the QR code with your phone.

>What if I can't use cross-device authentication because I'm on a locked-down work machine or one that simply doesn't have bluetooth?

Most devices today ship with Bluetooth and even locked down machines support using your personal phone to authenticate.

>What if I want to consolidate them all in one platform just for the sake of being organised?

Then do that. Use whatever your phone uses.

5 days ago

Sites should support multiple passkeys, and allow you to select between them if more than one are available.

I've seen this work on both Windows and iOS, where I have sites set up to use passkeys from multiple sources (Yubikey, Windows Hello, Apple Passwords, Microsoft Authenticator app), but I've also seen it not work, so there must be something the site has to do to make this possible.

okrad

5 days ago

This is more an indictment of the current state of password managers and the tension between them at OS-level and browser level

onel

4 days ago

Initially I've also struggled with this, and the mental model I found most useful is that a passkey is used to log in into that account from that device.

If the website doesn't allow you to add multiple passkeys then that's bad ux and that's on them.

modeless

5 days ago

Yeah, there needs to be a way to link password managers to share passkeys, and also to share passkeys between people. There are also a lot of great features that could be implemented with passkey sharing too, like revocation, time limits, or capability limits.

LocalPCGuy

5 days ago

Adding the kind of sharing it sounds like you are describing would just shift the attacks to that new attack surface. The attackers would basically try to trigger and intercept those shares.

If machines, browsers, phones etc are set up properly (yes, I know, big ask, especially with the confusion surrounding this, so I acknowledge the caveat), then the vast majority of passkey requests will go right into the preferred method (i.e. 1Password, Bitwarden, even Apple, browser of choice, etc). And most of those now will allow that passkey then to be used on a different device if signed in and synced.

I have found it to work pretty well with a password manager. I would suspect OS level passkeys would be much less "portable", especially across different manufacturer devices, like Mac/Windows, or even Windows/Android, etc. Which is why I waited to start using passkeys until I could use a password manager to store them, and I turned off all other passkey storages (same as I did for password storage before).

modeless

5 days ago

Obviously any new feature in a password manager is a new attack surface. That doesn't mean we should never add new features to password managers.

If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a properly designed sharing feature for passkeys.

FloydMorrisseau

5 days ago

I also don't understand why this was the only real downside off TOTPs brought up. "What if you input it in the wrong site?". Surely the exact same thing can happen with passkeys?

comex

5 days ago

It can’t, because passkeys are bound to specific domains and you simply aren’t given the option to log in with a passkey on the wrong domain.

seemaze

5 days ago

seemaze

5 days ago

Smells like FUD. Who's providing the ability to ban software? Providers are free to implement authentication requirements like SDC vs MDC the same way they can enforce minimum password entropy or maximum password age.

In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys. There are many more bespoke 'Authenticator' apps than there are passkey implementations, many of which disallow registering codes in third party wallets.

Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?

Telaneo

5 days ago

> Who's providing the ability to ban software?

The people who wrote the spec. If the spec didn't care about what software was being used to handle passkeys, they wouldn't have written in the ability for whatever you're authenticating to to know that.

The spec is bad and the people who wrote it should feel bad.

> In practice I'm aware of more 'lock in' behavior in the form of restricting which TOTP client is accepted than for Passkeys.

I've never seen this before. This reads like FUD to me. Every single site that I use TOTP with (40~ going by the number of secrets I have) didn't give a shit, and I don't see how they could, unless they use Super™ Special™ TOTP™ just because they're so special and wish pain and suffering onto their users. It's just a QR code you scan or a secret you manually type in, which then gives you some numbers you use later, and that's all it should be.

> Bitwarden also syncs TOTP. Given it's the same client, why push folks to opt for a provably weaker protocol with higher potential for user harm?

TOTP doesn't have a higher potential for user harm. If you use it with Bitwarden, the phishing resistance passkeys tout is something you already mostly get (you can still manually copy the code, which I believe to be a good thing, believe it or not).

Given how inconsistently passkeys are implemented and how it's more difficult to get at the actual data being used (unless you export them with Keepassxc (or Bitwarden?), the potential for fuckups is much higher with passkeys.

I'm yet to see someone get phished. It must happen, given that's how passkeys got started. But the far more common ways I've seen are sessions getting snatched and data leaks, neither of which passkeys protect against. It's a marginal benefit in exchange for so many downsides.

It's not FUD. It's just my opinion and a bad spec.

seemaze

5 days ago

>I've never seen this before

Microsoft, Apple, Adobe, Cisco, Steam to name a few.

>It's just my opinion

Fair enough. I find TOTP to be a PITA. I share your ire with user hostile platforms, but I see the passkey protocol as a net benefit to the status quo. It's unclear how a platform's choice to use a stricter version of the protocol is any different than their choice not to implement RFC 6238 at all.

Telaneo

5 days ago

> Microsoft, Apple, Adobe, Cisco, Steam to name a few.

I use normal TOTP with Microslop. Presumably you can opt into a worse version if you use their enterprise software, if you're evil or whatever.

The rest I presume fall into the bucket of 'wants to cause their users pain and suffering'. That's the normal modus operandi for Adobe and Cicso at least. The only one of those I use is Steam, and I haven't needed to log into Steam in over 2 years, since I'm just always logged in. Fair point though.

3 days ago

I just keep them in 1Password.

Has worked for me every time.

johanyc

5 days ago

> it could end up going to Google password manager, Samsung passWord manager, iCloud Keychain, or Windows Somethingorother.

Using all that is just asking for trouble. Turn all off except one.

5 days ago

Adding support for something to the spec implies that somebody is intending to do it, or why would they add it? This implies that someone is acting in bad faith (or openly promoting a malicious feature), and the best way for the others to show that they aren't in on it is to evict them from the room and strip out the thing they were trying to insert.

Taking it out doesn't mean you don't have to remain vigilant that they might try put it back, but what does it say if they're unwilling to take it out?

aleksejs

4 days ago

It's in the spec because enterprises use it for corporate authentication scenarios, where they do have legitimate reasons to restrict which kinds of authenticators their employees can use.

AnthonyMouse

4 days ago

Why is remote attestation required for this rather than just not issuing or enrolling authenticators you don't want?

Also, what are the legitimate reasons supposed to be that someone can't use an authenticator that follows the standard protocol but is made by a different vendor? The only thing the attestation actually does is make it so that you can't use e.g. GrapheneOS instead of Android, which has a tenuous relationship to being a legitimate prohibition.

akerl_

4 days ago

To pick a boring example: you run IT at a big company. You want all your employees using passkey auth, and you want it to be smooth for them, so you buy a bulk order of a couple thousand yubikeys and some glass fishbowls and plop a fishbowl full of yubikeys in the middle of each office.

Attestation means you can trust that nobody is accidentally or intentionally enrolling some random passkey-presenting device with rogue components.

We just had a front page story here this week about folks buying what they thought were secure hardware cryptocurrency wallets that had been modified maliciously.

AnthonyMouse

They also did nothing to quell my fears that they will in the future use passkeys to prevent people from using software they can modify themselves by saying "...the guidance for consumer sites has been to not even request attestation for years now." as if everyone always followed the guidance, and as if there aren't tens of thousands of managers that think their case is special and they really do need the extra control because they're a bank or handle copyrighted content or have PII or PCI and feel extra risk-averse today.

I don't know if they failed to do so because they can't (and this is a valid fear of the original author) or if they just are bad at reading the room at what the concern is and vastly overestimate how much people trust companies to always have their best interests at heart.

What I am getting from this, though, is "If you authenticate with a yubikey then that's attested, so they can't use attestation through passkeys to make sure your OS and browser aren't modified", and I'm not sure if that's the correct take away or even a correct statement.

AnthonyMouse

5 days ago

> If you can get attestation without those restrictions, "sure, why not", and a Yubikey seems like a way to do that which could avoid those restrictions.

Remote attestation is never to your advantage. To do it at all, they have to restrict you to a specific set of device manufacturers and yours may not be on the list.

Then, what does it get you? Google-approved Android phones are allowed, but any attacker can trivially get one of those so knowing it's that type of device is completely worthless. All it does is prevent you from using some other type of device.

Notice that this is different from keeping the key in a HSM, which you can do without remote attestation and without the other side having to do anything at all.

Worse, the "approved" devices often have worse security than the one you want to use, e.g. using a Yubikey as your HSM will generally be better than using a phone which has orders of magnitude more attack surface and is constantly connected to the internet, but the phone is way more likely to be on the approved list than the Yubikey.

5 days ago

Maybe I'm misreading, but that was my point - an app roots your phone but doesn't reboot yet, resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.

AnthonyMouse

5 days ago

> resets SecureBoot to the new configuration so it's accepted on reboot, triggers a PIN screen to re-seal user secrets, but it will now fail attestation since it's hashes will be non-recognized.

There are two types of compromise for the local device. The first is that they get root on the application processor (but not the secure processor), the second is that they get root on the secure processor.

If you have the first type of compromise then you don't need remote attestation because you can have the secure processor do any verification the remote server would have done and not release keys/signatures that allow you to sign into the service when the device isn't in the expected state. The secure processor won't accept a different device state for use of the existing key unless you compromise it.

If you have the second type of compromise then remote attestation can't save you because the attacker can forge attestations.

In neither case does it do you any good. The only thing it does in the first case is lock you out of using a device or OS you want to use because the service is demanding a signature from a specific OEM rather than one from the key you yourself generated and registered with the service and can keep in any kind of device you choose.

jmb99

5 days ago

You can’t change secure boot settings from the OS, even with root. You need the signing keys or to be in BIOS (if it’s configured correctly), which shouldn’t be on the device.

Now if the right kernel exploit and a secure boot exploit are chained together then it’s possible. But at the point, you’re gonna be hosed no matter what you do.

zahlman

5 days ago

> In a 2009 blog post, security analyst Joanna Rutkowska coined the term "Evil Maid Attack" due to hotel rooms being a common place where devices are left unattended.[1][2] Rutkowska then published a practical method for bypassing TrueCrypt disk encryption on victim devices, requiring merely an external USB flash drive.[3]

I hope the situation with disk encryption has improved. Otherwise, what is even the point of it? Any local malware you get is going to get an unencrypted view of the disk anyway (just like your legitimate programs) and there is already something seriously wrong if someone manages a remote login on a random home desktop that wasn't specifically configured for it.

93po

5 days ago

Yeah this article is confusing for me. The one a few days ago was basically saying "this is a slippery slope", which the post today acknowledges, then goes on to say "These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none" as though it invalidates the post a few days ago.

The whole point is that once everyone is accustomed to passkeys, they ARE going to ratchet it up to "you need attestation".

This is the browser wars all over again. Google spent something like 20 years winning the browser wars, and once they felt snug and secure, slowly started eroding users' abilities to control the content they see (making features adblock relies on increasingly ineffective).

1. Scott Helme is founder and CEO of Report URI, and Companies House records his ownership at over 25% and up to 50%. Report URI markets a "Passkeys Protection" offering, giving him a commercial interest in services for passkey adopters.

2. His WhyNoPasskeys.com campaign pushes websites to adopt passkeys, is sponsored by Report URI, and promotes its passkey protection services. The "Passkeys Are Not a Trap" article also carries a Report URI sponsor banner.

3. Troy Hunt, Helme’s Report URI business partner and investor, joined 1Password’s advisory board in 2020; Helme has also appeared in Hunt’s 1Password-sponsored content. That establishes an indirect vendor connection.

linkregister

5 days ago

Virtually every authority on passkeys is going to have an industry connection. Just like how most climate change authorities receive funding to do climate research, how SEC investigators typically have backgrounds in banking, open source military analysts are veterans, etc.

It's not because people are bought by the powers that be, it's the way the world works. People enter the fields they have expertise in.

rurp

5 days ago

The "biggest providers" bit at the end is odd too because the biggest providers are apple/google- who, as far as I know, do support attestation.

WorldMaker

5 days ago

Apple does not support Passkey attestation on consumer devices. They've said between user privacy concerns and user experience concerns (syncing and backup are critical requirements to non-technical users) they will not support attestation on consumer passkeys. They worked through the standards process to push compromise standards that are not attested but help with some of the "compliance issues" that might have come to require consumer passkey attestation (these are the uvi and uvm extensions which are not attested and essentially are "I solemnly swear a biometric unlock was used to access this key" for basic 2FA/MFA CYA).

So the "biggest providers" very much have some champions against attestation.

mahboi

5 days ago

Huh, good to hear. And this makes me not trust the article at all.

preisschild

4 days ago

> syncing and backup are critical requirements to non-technical users

hardware-bound webauthn tokens are also important since they are more secure

Fysi

5 days ago

A caveat to this is that you can use an arrested passkey on a consumer Apple device via something like Microsoft Authenticator.

WorldMaker

4 days ago

The big situation is enrolling an Apple consumer device under corporate management, which Apple calls "Declarative Configuration" and others call things like MDM. Declarative Configuration can turn on Apple's support for attestation (and is today "the only way" to get Apple's official attestation support).

Declarative Configuration is also the thing that allows the controlling corporation to remotely wipe the phone and other such things where they own the phone more than you do.

I know not every person has the luxury of telling their employers that they will not install corporate apps on personal phones and that if their employer wants to own their phone they should pay for a separate work phone. But that is the big scenario to avoid attestation becoming more common in the wild, making sure people realize that "No work apps on personal phones" is maybe something worth striking about.

mahboi

5 days ago

And supposedly Microsoft Authenticator refuses to run on a jailbroken iPhone

_bent

5 days ago

The author is really missing the forest for the trees here

So if I was Netflix or a bank or w/ever I'd only allow new registrations from "trusted" authenticators, which would incidentally only run on iOS and play-protected Android.

linkregister

5 days ago

The next paragraph states that Yubikeys are a registered authenticator. Yubikeys are platform-agnostic.

dingaling

5 days ago

A closed-firmware USB key is really no better option.

5 days ago

Correct.

PaulHoule

5 days ago

GP here:

(1) The use case I have seen is that a startup or small unit in a big organization has subscriptions to a number of services that are shared by multiple users; if I had to log into one of these things I would log into the password manager and use the username and password that we all share -- these have never been things that I use for my day and day out software development but usually are things the marketing people use that I only have to log into every six months or so if I have to help out with a problem. I've always had individual accounts for bread and butter services such as version control, issue tracking, documentation management and such.

5 days ago

The arguments of they never "usually" do this, or "the guidance says" are meaningless. Whatever can be used for control, will be.

EA-3167

5 days ago

When you’re dealing with people so persistently stupid that they haven’t figured out the value of seatbelts, while still generally insisting that the costs of their medical care are socialized, my appreciation for the necessity of social control is enhanced rather than dampened.

cferry

5 days ago

When it comes to attestation, it's purely promoting business and state interests against yours. No security comes with it, it's purely control.

Imagine being the owner of a small business who is now required, to do business with any providers, to have a rogue executive that is loyal to them rather than you, and overrides your decisions; your provider refuses to sell you any materials if this executive is not obeyed. Do you think any business owner would accept that? I think on the contrary, this practice would be outlawed by Congress or the relevant legislative body in a matter of weeks. Those who voted seatbelts in. Then it's exactly that, if you replace business by computer.

EA-3167

5 days ago

You’re telling a story and the story is consistent, but it’s still a story. Besides you’re making a lot of assumptions about me, my beliefs, and what might be of concrete benefit to me.

gf000

5 days ago

It happens now with 2fa today. I have gone through college for 4 years having to use this shitty duo mobile app and we have to take out our smartphones 20 times a day to do things and re-login after every 20 minutes.

5 days ago

Most consumer websites won't demand you share a scan of your face to third parties, until they do. Same exact thing will happen with passkeys, guaranteed.

the_lucifer

5 days ago

Exactly how http was the standard for normal websites and banks et. al. using https until, everyone was.

Now that was a good thing with https, not so much with passkeys until Chrome pushes through a change and says they'll only accept attested passkeys issued by their own google password manager/authenticator.

the8472

5 days ago

Adding HTTPS everywhere was not "a good thing", it's coping with a civilizational coordination failure that shifted us to a lower trust equilibrium. We're paying the price for that in an endless update treadmill for clients and even for read-only webservers. And more compute-cycles and latency spent on the encryption handshake. We also lost caching HTTP proxies. This is bad actors creating a negative-sum outcome.

rcxdude

4 days ago

Not encrypting by default is a ludicrously unstable position as far as trust 'equilibrium' goes. It would be an astounding feat of coordination to avoid needing it as the internet grow, probably one that would cost far more than https.

the8472

2 days ago

Conversely, exploiting the the lack of encryption would also be an unstable position because the world then shifts to encryption, voiding your access. So you're trading a one-time benefit to yourself against permanent ongoing costs for the whole world.

I know that humans are poorly equipped to solve these kinds problems, but it still is lamentable.

user

5 days ago

[deleted]

zaptheimpaler

5 days ago

Access is a good thing too. I don’t want hardware attestation, i want to be able to access my bank from anywhere. Banks continually push their liability for security onto customers.

warkdarrior

5 days ago

> Banks continually push their liability for security onto customers.

Bank customers: "You don't need to know anything about me."

Also bank customers: "You need to stop anyone who is not me from accessing my money."

Capricorn2481

5 days ago

People who are more tech libertarian don't like when critical aspects of their life requires a smart phone from either Apple or Google. The ability to avoid these companies is becoming increasingly difficult, and attestation is one piece of that puzzle.

I don't think that means throwing out passkeys entirely, but that's why you're seeing a lot of "slippery slope" stuff in here

tantalor

5 days ago

Well those people can buy a YubiKey for $30 I guess. I don't see why that's a big issue.

debazel

5 days ago

Why do you think YubiKey would be an allowed option? Sites will require Google/Apple password manager and use this as a proxy to prevent bot accounts.

Capricorn2481

5 days ago

https://github.com/keepassxreboot/keepassxc/issues/10406

"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations)."

"This implementation is not spec compliant and has the potential to be blocked by relying parties."

Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.

mik1998

5 days ago

These are very damning. Pretty straightforward about removing all software freedoms in favour of some sense of security. It really is already happening:

msdz

5 days ago

> it sucks

Exactly. From the page about the requirements for the app under 1) in your link:

> System requirements

> Android 12 or iOS 16

So one of four methods is, by default, already completely dependent on having an account with $american_megacorp.

4) is another app where it doesn’t outright say, but I’m guessing the requirements are also a mainstream OS, mobile at that as well since they seem to use biometrics.

5 days ago

I’ve seen tech-savvy people getting phished into entering their password on a fraudulent site, despite the password manager blaring alarms that the login looked fishy.

This cannot happen with passkeys at all because crypto magic.

hbn

5 days ago

I assume a phishing site wouldn't even attempt to use the passkey because it can't. So wouldn't it just ask for a password, and at that point, if you're gonna fall for it, you'd go and grab the actual text password anyway?

My password manager matches off of domains too, so it wouldn't suggest to autofill on a phishing site.

loloquwowndueo

5 days ago

Right. It didn’t suggest it but the phishing message was convincing enough that the tech-savvy person fished the password out manually and input it anyway. A mistake for sure, and one the password manager was trying to help with, for sure, but this mistake would have been impossible with a passkey.

joshuaissac

5 days ago

> this mistake would have been impossible with a passkey.

But GP is saying that when the passkey is not auto-entered, the user will just use password-based login.

So the mistake will still happen even if passkeys are enabled and used, as long as password-based login remains as an option.

kllrnohj

5 days ago

> as long as password-based login remains as an option.

which they have to be, right? since passkeys are "temporary" in that they are easily lost/destroyed/temporarily unavailable, and sites are supposed to support multiple of them?

MrDOS

5 days ago

Right. The “correct” way for a service to handle this is to disable password logins for any account that has enrolled a passkey. A few services do this, but boy howdy is it ever unfriendly to users (or at best, difficult for them to get their heads around).

makeitdouble

5 days ago

> This cannot happen with passkeys at all because crypto magic.

That's way too optimistic.

The core reason people enter the password in different domains is because most services suck at keeping a canonical login page. That forces users to register multiple URLs for a single credential. And from times to times, they hit a page not within their registered urls, will login and just add the new url to the pool.

Will these services magically become super competent because of passkey ? I'll respectfully doubt it.

They might not screw this specific aspect, but they'll screw enough other things that users will need to keep injecting password somewhere from times to times.

mixdup

5 days ago

What's the difference between using a really good password vs. public key authentication in SSH?

bvrmn

4 days ago

It's bad analogy. webauthn is quite far from just a protocol to verify keys.

whyagaindavid

5 days ago

> What would I gain from using a passkey?

The correct question is What did others gain?

- Phishing free press fingerprint or faceID or Windows Hello for login into many important sites

- many people don't have time to type password, then otp. If most of the world did that then this would not be needed.

- And finally, YOU are not OBLIGED to use it. Let the rest of population use it.

- It is like SOME pay with phone/NFC-Watch etc. MANY still use card or cash...

Capricorn2481

5 days ago

> And finally, YOU are not OBLIGED to use it. Let the rest of population use it.

They are.

abraxas

5 days ago

My OS (Arch), my browser (Firefox) and my hardware (Yubikey) all work fine with some sites. For example my Google account credentials are on my Yubikey passkey. But half of the sites that claim to support passkeys won't offer me the option to save the passkey on my hardware. Paypal is one such example. Facebook is another. I don't understand why. They seemingly only want to cooperate with cloud based passkey storage. I don't know what mechanics govern this.

jeroenhd

5 days ago

Paypal refuses to offer generating a passkey on either Firefox or Chrome on Linux. Spoofing the UA to Firefox on Windows does work, though. Whatever they're doing, it's not normal. I'm surprise you run into it so often.

This is the first time I've seen this issue, very weird. Then again, I had to apply some kind of hack to enable TOTP back in the day (something about faking an RSA key fob), so I'm not surprised Paypal is stil shit.

rcxdude

5 days ago

> OS-supplied keychain management

That is your choice as the user. You can use the default credential manager that is offered out of box, or you can use your own.

https://whatarepasskeys.info

Whitespace

5 days ago

No, you can't just use whatever passkey manager that you want.

I use Safari, Chrome, MacOS, a Google Pixel phone, and 1Password. I have passkeys in 1Password, but it's a crap shoot if I'm able to login on a device.

Chrome wants me to use Google Password Manager. There's no option in chrome://settings to set 1Password as my passkey manager. If I try to use a passkey to login to GitHub Chrome pops up a modal that lets me choose between iCloud Keychain, Use a phone or tablet, or USB security key. There's no option to use a different credential manager.

Safari wants to use my iCloud Keychain. There's no option in MacOS Settings to set 1Password as my passkey manager. If I try to login to GitHub I get an option to Scan QR Code or Use Security key. There's no option to use a different credential manager.

My Pixel wants to use Google Password Manager. There *is* an option in Pixel Settings to set 1Password as my passkey manager, but it doesn't work in Chrome. All I can do it select "use another device" and it shows a QR code. There's no option to use a different credential manager.

Essentially every OS and browser thinks I want to use a phone for my passkey, and this is exactly the situation that I and everyone else is bothered by. I do not want to tie my login credentials to a phone that can be lost/stolen/bricked and will be replaced in several years.

So no, you can not use your own credential manager.

stmw

5 days ago

Great examples, exactly what I'm saying. And every one of these (browsers, OSes, phones, etc) has strong incentives to only offer its own password manager.

timmyc123

4 days ago

You wont' typically see a setting in your browser, because credential managers are designed to operate at the system level, so that your credentials aren't "stuck" in your browser. This is why you don't see an option in Chrome settings. You can, however, disable Google Password Manager in Chrome settings, as it is a Chrome feature.

macOS: Settings > General > Autofill & Passwords. Turn on 1Password. https://support.1password.com/macos-autofill/

smw

5 days ago

What are you talking about, I use the bitwarden extension in chrome and chrome never asks me to store a passkey, bitwarden does.

stmw

5 days ago

It's notable that several of the claims on that page conflict with the other info in both the OP article and the follow-on.

As for choice as the user, it's a choice "for now"... and only for users who understand all of these details (which seems unlikely).

Personally, my observation is that if one tries to properly configure 2FA with any major website lately (no, I don't mean AWS console), the level of "your choice" and properly implemented security has actually gotten worse...

timmyc123

4 days ago

> It's notable that several of the claims on that page conflict with the other info in both the OP article and the follow-on.

Create GH issues or use the feedback form if you believe there are issues with the content!

mzajc

5 days ago

Much like you could use any AOSP fork to run banking applications... until you couldn't. But hey, at least there's an explainer website[0] that completely glosses over this detail.

[0]: One great bit of environmental storytelling is the "Made with <3 by the passkey community" in the footer. "Passkey community" of course means timcappalli with minor contributions from two others. You might remember him from https://github.com/keepassxreboot/keepassxc/issues/10407#iss....

littlecranky67

4 days ago

5 days ago

Recent and related:

Passkeys are a trap - https://news.ycombinator.com/item?id=50048312 - Oct 2026 (571 comments)

Ricky Mondello responds to "Passkeys are a trap. Do not use them." - https://news.ycombinator.com/item?id=50061290 - Oct 2026 (14 comments)

dllu

5 days ago

I recently had the displeasure of using Passkeys:

- trying to sign in to Okta on my personal Linux desktop computer. It has bluetooth and I had my phone right next to me, also with bluetooth turned on. But Firefox simply refuses to even show the option for "connect to your phone" or to give a QR code... it just said "tap your security key or biometric device". I had neither; my passkey is on my phone. Then it timed out and I gave up trying to log in.

- trying to sign in on my work Macbook using Google Chrome (enterprise managed one). For some reason, upon scanning the QR code, my phone was stuck on "Connecting..." and timed out. I had bluetooth turned on on both devices, they were five centimeters apart, both were connected to internet with a great gigabit connection. It turns out, I had to quit and restart Chrome and it magically started working.

- trying to sign in on my work desktop using a physical Yubikey remotely using VNC. It's not possible by design. I had to get my coworker to press my Yubikey in the office.

- trying to get Muse and OpenAI Dot to sign in using a passkey. It's not possible by design.

Generally, the user experience is really horrible with passkeys. It is also ironic that it trusts my phone (used for shitposting; easily lost or stolen) instantly, but simply refuses to trust my personal Linux desktop computer, which is fully encrypted, securely stored in my house, and contains all my life's work and everything that is dear to me.

sdcfgy

5 days ago

Let us consider the average user. The one who manages to lose their iPhone and has no idea what their iCloud account login is because they were aware of having to log into it once when they created the account at phone purchase 3 years previously.

That's where the trap is.

jon-wood

5 days ago

That person is fucked when they lose their phone anyway, because they're also the sort of person who has never backed up all their photos/contacts/iCloud files anywhere that doesn't require iCloud auth to get at. At some point we have to either properly educate people on the fact that they need to have a recovery path, or we have to accept that they're going to need to rebuild their entire digital life every 2-3 years.

This is your cue to go get your parents to add you as recovery contacts for their Apple account now, rather than finding out that exists when they lose their phone.

TheSkyHasEyes

5 days ago

This is presumptuous. Many people back up their devices and have no idea how they did or whether or not it succeeded. Seen it many times(fortunately).

> That person is fucked when they lose their phone anyway

I am hoping nowadays most people lock their devices. I rarely see unlocked in my adventures anymore.

MatrixMan

5 days ago

Compared to some of the harms that will come from platforms abusing attestation, rebuilding your digital life every 2-3 years is no big deal.

mixdup

5 days ago

As long as they didn't turn on the advanced protection features on their account they just go to the Apple Store who can help them get back in

linkregister

5 days ago

Impossible. Because iPhones randomly force you to enter your iCloud password, often at the worst possible time. Such a user would have already been prevented from signing in to their own iMessage on a random Tuesday afternoon.

One of the most frustrating issues with Apple's UX.

jeroenhd

5 days ago

I've never experienced that. The only time I've entered my password was when I set up the iPhone and when the phone got into a weird state after a software update.

WorldMaker

5 days ago

It seems to vary with how often you purchase things from the App Store and iTunes Store and how "high value" your account seems to some sort of iOS metrics. Which is why it also often seems like "phone is in a weird state after a software update" as that is probably also when some of these metrics reset/get rechecked.

dogleash

5 days ago

It depends. It sounds like you're all in on the ecosystem. I only have the apple account because I have an iphone. I didn't get one of those double check reauthentications since many years ago, up until last month when I got apple tv. I know because I had to reset my password and it was older than my use of a password manager.

jerf

5 days ago

I think the passkey standard included attestation for good reasons, but it is obviously also possibly a trap in the sense that I'm sure there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.

I have to admit I don't worry too much about the entire internet flicking attestation=true anytime though, because the resulting support nightmare would be ferociously expensive. I wouldn't be surprised that, on its own, it would be more expensive than the cases that the companies flipping the switch are trying to avoid. Which means it isn't going to happen.

The simple truth is metaphorical-Grandma can't handle the degree of responsibility put on the user that strict hardware attestation implies. Netflix et al are more likely to want metaphorical-Grandma's money more than an incremental improvement in their ability to be sure it's an attested login, and won't want metaphorical-Grandma to call Netflix every other week trying to figure out how to log in again. There is no way around the fact that strict attestation implies more user responsibility to make sure they don't lose their token, and at scale, they absolutely will. Work environments can get away with this because work environments have a scalable mechanism to re-verify identity to the extent the business cares about it personally, and reissue tokens. At scale the big companies do not have this for individuals. You can't use hardware attestation without this infrastructure for reverification, and any infrastructure for reverification a large corporation tries to create will have exploitable holes in it.

mzajc

5 days ago

> there were some people on the standards committee(s) envisioning a glorious world where they can flip this on for everyone and instantly all the bad stuff stops.

Why the past tense? Here's a list of FIDO Alliance board members: https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO_members. I would love a spreadsheet with their positions on remote attestation - let's start with the banks.

davexunit

5 days ago

I don't use passkeys but the thing that raised a red flag for me while reading the article that the OP is responding to is the "non-copyable" property. It's not possible to prohibit delegation[0], so the idea that a key can only be used on one specific device necessarily involves a form of DRM/wishful thinking.

[0] http://www.erights.org/elib/capability/delegations.html

hedora

5 days ago

The entire point of passkeys is to force DRM onto all corners of the web. It lets sites require attestation of the software running on the client device. Once they use that to eliminate hardware and operating system competition, they’ll ramp up surveillance and censorship even higher than current windows levels.

Passkeys are the second prong of the age verification push.

If you want more evidence, read up on Project 2025’s plans for forcing the internet to adhere to American Christian Nationalist values, then try to figure out how that could work in the absence of passkeys.

davexunit

5 days ago

Yeah I think the OP is being naive about the risk here.

linkregister

5 days ago

I do not think there is adequate reason to believe that FIDO Alliance members are supporters of Project 2025.

OkayPhysicist

5 days ago

There is plenty adequate reason to believe that they are authoritarian assholes hellbent on stripping users of control, though. Scroll up a bit and read about the KeypassXC incident, and tell me that is the stance of an organization with user empowerment as an even distant value.

The fact that the attestation field exists at all is damning proof that they made overt plans to move in that direction. Passkeys are the mark of the beast, friends don't let friends use Passkeys, etc., etc.

davexunit

5 days ago

I think there are a number of people who mean well that aren't aware that they are creating the means for state control of computing.

ForHackernews

5 days ago

This author is astoundingly trusting.

5 days ago

Google today might not do that, but Google tomorrow, when some upper manager's multi-million dollar bonus gets tied by a performance metric on how many people are using passkeys for gmail would in a heartbeat.

hedora

5 days ago

If they are not a trap, then the standard should be amended to allow third party implementations to forge attestations.

Otherwise, it is a trap. The story of the last 25 years of the internet is user hostile ratcheting away of the open web. Passkeys are obviously another step in the process.

_jackdk_

5 days ago

https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

> To be very honest here, you risk having KeePassXC blocked by relying parties

This threat, because someone dared to give users control, is completely unacceptable to me.

verdverm

5 days ago

every time I've been prompted for passkey setup, it says things like "this is easier, just give your fingerprint"

no thanks, passwords are not a burden to me

psanford

4 days ago

I don't ever see that

mahboi

4 days ago

It's a thing, but mainly because they assume you're using a smartphone with fingerprint enabled.

canjobear

5 days ago

What makes you think the government can’t compel you to provide a password?

verdverm

5 days ago

Case law and court rulings

goda90

5 days ago

I don't find this post convincing.

> If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

This isn't a rebuttal to the claim that they're a hidden dial. It's just saying that it's too early to crank the dial.

>Attestation Isn't What You Think It Is

>The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.

>When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

This point is bypassed by websites only supporting specific authenticators and then those specific authenticators only supporting specific devices/OSs/browsers/etc via other attestation frameworks.

flumpcakes

5 days ago

Then guess what - people stop using those websites.

The big players who want to gatekeep you in their ecosystem do not want attestation - they want you to give them your passkeys for them to store under the guise of "hey, we'll sync it for you!".

A yubikey is easy to use. Buy a second as back-up. If you're clumsy and lose things all the time then set up recovery codes. Add a recovery contact. Use insecure 2fa like TOTP or really insecure 2fa like email/sms/etc. codes.

There's plenty of options for authentication in the modern world and passkeys are at the top. If users are 'too stupid' to use them then that's a user problem.

I'd rather spend the 5 minutes reading how these things work and then not hand the keys over to big tech.

zootboy

5 days ago

> Then guess what - people stop using those websites.

Wishful thinking. Sadly, the vast majority of people will be perfectly OK with a website telling them they have to use a recent iPhone or Play-enabled Android phone to do something. This is already the case for banking apps and a huge number of other phone-app-only services.

goda90

5 days ago

Only a few people stop using those websites, because most people will use the Apple or Google authenticators and be done with it. And if those websites are essential services, those few people who don't conform will be left out in significant ways.

xigoi

5 days ago

5 days ago

I have to say the messaging around passkeys is bad. So many providers show modals with big friendly lock logos superimposed on a smartphone to announce the change without offering any explanation about why the change is happening, why the change is happening now, or how the technology works.

I don't know when it started, I don't know who is to blame, but we've definitely arrived at a conceptualization of "the user" that is passive, uncurious, and incapable of being talked to like an adult.

proctorg76

5 days ago

It was usenet mods, in September 1993, with the candlestick.

adjejmxbdjdn

5 days ago

Let’s assume passkeys are the greatest thing since sliced bread.

Passkeys face the same problem as the USB-C rollout. Lots of different incompatible implementations and standards rolled under one name that are almost impossible to distinguish between. Very little education on how to use it and be prepared for it.

The difference is that the consequences of getting passkeys wrong for the user is significantly greater than getting the wrong cable, and while the latter can easily be fixed, the former may be irreversible.

jeroenhd

5 days ago

I hope passkeys are the same as the USB-C rollout. The internet whines and complains for a few years about their theoretical device from 1999 that won't work anymore and then everything is just plain better for years to come.

qlte

5 days ago

Sites that implement passkeys need to have an account recovery mechanism. Granted, not every site does this correctly. Don't use passkeys on sites that don't have a recovery mechanism!

Secondly, the site you're authenticating to must allow you to have multiple passkeys. You either have a cloud-synced password manager so that all of your devices get the same passkey, or you have a passkey per device that you use to access the site. Again, not every site allows multiple passkeys. Don't use passkeys on sites that don't allow you to have multiple passkeys.

For a site implements both of these properties correctly, if you lose your device, you just connect to the site with your new device, perform whatever account recovery procedure (TOTP, email verification, phone verification, ...), create a new passkey, and, ideally, disable the passkey from your lost device.

OkayPhysicist

5 days ago

The problem with "sites must allow you to have multiple passkeys" bullshit is that sites aggressively push you towards making that first passkey, but then hide the process for adding additional ones 6 layers deep in settings such that a typical user will never see it.

I literaly just had to unfuck my grandfathers webmail because of this garbage. "oh, I can only log into my email on my ipad now" and I immediately knew the shadowy cabal of evil over at the FIDO Alliance were to blame.

It is up to us technical users to make sure the other 90% of society don't fall for this shit. Tell them it's the mark of the beast, tell them that it's fascists seizing control of your identity, tell them whatever will make them run for the damn hills anytime they see "alternative ways to sign in".

mahboi

5 days ago

TOTP was kinda like this too. The standard was fine, but actual implementations like Google Authenticator disallowed copying keys to another device, saying this is WAI and you're supposed to set up a separate TOTP per device. Absolutely user-hostile and took several years to fix.

Passkeys did better day 1 because they synced, probably just cause password managers are better now than back in the TOTP days. But for some reason the standard has a way for them to force you to use like a WEF-approved KYC passkey store.

cpburns2009

4 days ago

I for the life of me cannot understand how these three things coexist about passkeys:

1. They should be locked down to a single device.

Most of those organizations have shown that they don't want people owning their own devices or being able to run their own software, and they use developer attestations, IE a revocable programming license to accomplish that.

Tools like android's safetynet makes it so that you can't run banking apps on a phone running your own software. One that bypasses developer attestations.

Passkeys are currently an open standard, but attestation is built in such a way as that it could be only usable on n approved operating system with programmer licenses.

Big websites like amazon, or websites you need to exist in society, could gradually start requiring the usage of attested passkeys.

---

There is a clear path from passkeys to the death of general purpose computing for 99% of people. Don't be a useful idiot, don't assume these corporations have your best interest in heart. See this for what it is, a path towards killing people's ability to run unlicensed software on their own devices.

LocalPCGuy

5 days ago

5 days ago

As if the police in a corrupt state are going to check the public fingerprint of your passkeys. Your account identifier is proof enough.

The make and model of your authenticator is shared with about 2 million other Yubikeys, if anything they'll compare your public key, not the attestation process.

nogridbag

5 days ago

5 days ago

Last time I tried using Firefox on Linux with Keepass's passkey implementation it worked on the test page and a couple other sites but Facebook refused to add it, so I definitely believe that e.g. banks and various other important sites won't balk at restricting passkeys to Android, iOS/MacOS, and Windows. I am curious what other people's practical experience is with these kinds of sites.

mlfreeman

5 days ago

I've set up a few passkeys to see what it's like and the experience is wildly different between sites.

State Farm is the only place I've actually liked it. I don't have to type ANYTHING in.

Open browser, open password manager, click the "sign in with existing passkey", browser and password manager talk, prompt me to confirm the passkey choice, and I'm in.

Most sites I've messed with insist on you entering a username first.

jeroenhd

5 days ago

> Most sites I've messed with insist on you entering a username first.

A lot of them do that to detect if they need to trigger an SSO flow. It's awfully annoying. Things get extra fun when a website migrates from email+password to SSO and suddenly you have two accounts that both exist in their system, one of which doesn't work if you hit enter before the SSO javascript redirect happens.

jgrahamc

5 days ago

I find the following has the right combination of mental model and security for me:

1. A password manager that generates my passwords stored on an external USB key (which is itself encrypted). I use KeepPassXC.

2. More than one Yubikey doing U2F.

I know how to backup #1 and I have more than one of #2 to handle losing a Yubikey. #2 gives me phishing protection.

Velocifyer

5 days ago

For me, randomly generated passwords(via proton pass) combined with remembering to check the URL stops phishing and is easier to share.

alterom

5 days ago

Passkeys are a solution for a problem that the users didn't have (website security).

And the solution was: make it the user's problem.

Yay.

mzajc

5 days ago

I was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.

I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.

And yes, passkeys absolutely ARE a trap.

[0]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

nonfunctional

5 days ago

I put a reply to this article in the comment section of "Passkeys are a trap. Do not use them."

https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...

zb3

5 days ago

"Model of the authenticator" could say almost everything about these if the model was let's say "Google Pixel 10". TEE would refuse to sign the attestation if the bootloader was unlocked / AVB didn't verify.

YubiKey attestation is not a problem because the device doesn't work against me in such a way it would require installing custom software on it. And even if YubiKey went crazy, they're not a monopoly.

Situation with smartphones is very much different..

sega_sai

5 days ago

I simply was not convinced there was a tangible benefit over password + 2fa when using a password manager. And the inability to move the passkeys is not acceptable. Similarly the failure modes of the passkeys vs password + 2FA were never clear.

5 days ago

I use ProtonPass on every device I own (religiously) and have never had an issue. But it's because I'm very careful to only deal with any credential ever via ProtonPass.

I can imagine it gets annoying very fast if you accidentally put a passkey in the wrong place, ie because Chrome proposes it's own credentials store.

ProtonPass also lets me export the private parts so I'm not stuck as with some passkey managers.

Passkeys are great but require you to understand some things about them, and you need discipline in dealing with them.

throw7

5 days ago

As far as I've read here before, device attestation is definitely there, it's just not being used (one of the big tech namely Apple is balking... maybe they have their own means or plans in their ecosystem).

My main reason for not using it is I'm not interested participating in a scheme where I do not own/access the private keys and being able to use them and store them the way I want to.

I'm fine with TOTP and sure, I understand it's not phishing resistant by itself.

doc_ick

5 days ago

[dead]

hobo123

> WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up.

How's that not just a terrible idea that leads to all of the aforementioned scenarios?

By adopting this you give the site ability to require a specific app and/or hardware for keeping your keys.

apexalpha

5 days ago

I introduced Passkeys in my company.

Every single IT person thought it would be an extreme mess, too complicated for regular users. In my company we work on the (gas) grid so lot's of blue collar types.

We went there, gave the pilot group a Yubikey and said: This is like the company pass you already have. Without the company pass you cannot enter any buildings. Without the Passkey you cannot enter a computer or app.

If you lose it report to the same people (service desk).

The response has been EXTREMELY POSITIVE. People fucking LOVE getting rid of passwords, password requirements and taking off their gloves to enter it every time.

We are now rolling it out to everyone and next year when we stop our silly "phishing game" contract we will actually save money while reducing a massive cyber security risk for our company: (voice) phishing.

cesarb

5 days ago

> If you lose it report to the same people (service desk).

THIS is the reason it worked great for your use case. You have a stopgap for the worst case.

You also have a limited, well-known, and mandated set of compatible software and hardware. And you don't have to worry about attestation preventing you from using any future hardware or software, because you have control over any attestation whitelists.

The scenario people worry about is not "passkeys being mandated by your company to access company webapps on company-provided devices, with easy access to in-person passkey resets". The scenario people worry about is passkeys making them lose access to third-party sites on their own devices.

apexalpha

5 days ago

I think my use case covers >99% of all organisations.

roosterIllusi0n

5 days ago

Perfectly fine in a business environment where you don't have privacy. It is unacceptable for any personal computer(including phones) to be leaking unique ids so you can be tracked.

apexalpha

5 days ago

What's the unique id leaking issue?

I mean you're logging in to some software, surely they need some info from you?

hedora

5 days ago

Passkey attestation hands control of the client software to the website. Since surveillance capitalism funds most of the web, this means that, over time, the only approved clients will be surveillance devices, and those devices will slowly add more and more invasive spyware.

roosterIllusi0n

5 days ago

"AAGUIDs are unique identifiers assigned to FIDO authenticators (including passkeys and security keys) and are used to identify authenticator models for attestation and metadata purposes."

If there is any unique id that can track you, then it's a trap. No security system should be leaking unique ids that can be used to track users.

timmyc123

5 days ago

AAGUIDs are not unique to authenticators. Hundreds of millions of people using the same product have the same AAGUID.

xoa

5 days ago

I think it's a bad sign when someone immediately resorts to strawmen and argument from incredulity in their counter-argument:

>If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that?

The original didn't argue that, nor has absolutely anyone else concerned, nor has that been what has happened in historical examples people were concerned about. Because yeah of course that's ridiculous, it's "boiling a frog" by throwing it in already boiling water, that's not how it works. If anyone has freedom-reducing longer term plans for use of passkey attestation, the emphasis is on "longer term", being malicious doesn't mean being stupid. Step 1 is obviously getting people into the passkey ecosystem and out of passwords at all, which could well take years. And importantly as much as possible into closed passkey ecosystems. This is indeed one of the initial danger signs, because the author:

>iCloud Keychain, Google Password Manager, 1Password, Bitwarden

Is mixing together things that aren't like the other. Quick author, what's the EXPORT story for each of these ecosystems? Of those, Bitwarden can export a passkey into a plain JSON if you want. Do the others support that too, or at best only "app to app" encrypted transfer, creating a closed ecosystem? Already, can I get passkeys from iCloud/Google/1Pass into KeePass? Or is this restricted """for my protection :^)"""?

Author doesn't even touch on the lock-in that's already beginning. And right now everyone can technically claim "oh no of course you're not locked in! You just have to use an official option, or you can merely visit hundreds of sites individually and register new passkeys in all of them". Is it hard to see how players like Bitwarden would be pressured on continuing to offer plain export?

Anything else IMO is doomed to fail. More sites than not can't be bothered to use input type="email" or type="number" when all they accept is numbers or email. What hope do we have they'll use passkeys correctly?

user

5 days ago

[deleted]

zaptheimpaler

5 days ago

The counter-argument he makes against people's concerns about attestation is laughable, all he says is that it hasn't happened yet.

Passkeys are not designed just for security, there are other corporate interests involved. It's impossible to share logins for example. He even mentioned this concern and didn't address it.

The device/app lockdowns are already real for TOTP - Microsoft and others insist on using their snowflake authenticator instead of using the standard protocol. So it's not unlikely that they will extend that kind of lock-in to all passkeys.

timmyc123

5 days ago

Lot's of additional great information for consumers and prosumers at whatarepasskeys.info. Many of the questions that are constantly discussed in these comments are answered in the FAQ and content.

Contributions and feedback are welcome! GitHub link is at the bottom of the page.

mahboi

4 days ago

Why are passkeys designed in a way that I can't copy the private key as text to import into whatever password manager I want, even as an advanced user?

timmyc123

4 days ago

You can. Choose a credential manager that offers that feature.

I just don't think that's a good idea for most users. Imagine an older relative being coaxed into exporting all their passkeys in plaintext and uploading them to a website.

mahboi

4 days ago

There's seemingly no password manager that lets me export the passkey as plaintext, at least not on a Mac. At best I can hand off to another app, which only works from Keychain and nothing else, and can only go to a preset approved list of apps like 1password. iPhone situation is a bit better, at least I can transfer from 1password to other things, but again it seems like a whitelist and there's no way to just get a csv.

Besides all that, the standard supposedly supports types of passkeys 1. bound to the device (not a security key) that cannot be handed off at all, or 2. can only be used in certain apps. I'm guessing the first case is more for corps that only want employees logging in with issued corp devices, but why the second one?

Everything has conditions, which is why I'm wondering why this isn't just an unconditional "yes, it's your key, do whatever you want."

Havoc

4 days ago

So we have one article that contains factually questionable info and one article is written by a biased source.

Can’t wait for episode 3! Hopefully someone knowledgable pulls it all together into a season finale

user00005

5 days ago

I'm moving my HSA because the company moved to passkeys.

I use unique email addresses and passwords, stored only on my devices(Linux, Windows, Android) using open source software (KeepassXC, KeepassDX). Passkeys add new friction I don't need.

user

5 days ago

[deleted]

happyopossum

5 days ago

Almost every complaint I see about passkeys seems to be based on behavior and configurations I just do not see in the real world.

“Once I set up a passkey I can’t log in from another device” - have never seen this to be the case. Existing password / OTP codes have always worked as a fallback if syncing somehow breaks.

“I don’t want to trust Apple/MS/Google with my logins” - so don’t. Use bitwarden or 1Password or lastpass or whatever you want to store your passkeys.

“If I lose my phone I’m screwed” - see #1 and enable sync maybe?

Boils down to I believe a lot of folks looked at passkey implementation at a high level, saw some potential pitfalls, and never actually used them to discover those pitfalls have all been accounted for.

Go ahead and skip passkeys if you want, but stop preaching about evils that don’t exist.

mahboi

4 days ago

People used to complain that some password managers like Keychain don't let you transfer passkeys at all, but this was fixed. The problem is, passkeys can designate themselves as non-syncable and/or only allowed to be stored in certain password managers / hardware.

There are comments here about companies that already force the use of Microsoft Authenticator, which forces you to use a locked-down phone.

OkayPhysicist

5 days ago

“Once I set up a passkey I can’t log in from another device”

This literally happened to my grandfather yesterday (well, I found out about yesterday, anyway). Dude just casually mentions that he can only log into his webmail on his iPad, and I immediately knew what was up.

"so don’t. Use bitwarden or 1Password or lastpass or whatever you want to store your passkeys." -- All fine and dandy until they decide to start using that attestation feature that they 'pinky promise' they won't use for nefarious purposes.

Passkeys are literally evil, and exist exclusively because 1) companies are evil, and want nothing short of complete and utter domination of their users' lives and 2) one CEO is embarrassed that he was too stupid to realize that "my password manager isn't autofilling" means "I'm on the wrong website".

DauntingPear7

4 days ago

2> Device-Bound Software Passkeys (e.g., Microsoft Authenticator app on a phone): Only inside the physical device's secure hardware chip.

3> Device-Bound Hardware Passkeys (e.g., YubiKey, RSA iShield Key): Permanently burned into a dedicated physical USB/NFC chip.

I advocate for "Device-Bound Hardware Passkeys," but not many websites support them. Keeping a duplicate hardware passkey is important in case the original hardware key is lost.

efields

5 days ago

I figured they weren't. People smarter than me made them.

I think they've been implemented well in some cases. I think they've been implemented poorly in others.

So it goes.

INTPenis

5 days ago

I mean the desire to trap seems to be among the big corporations already.

I keep seeing major players promoting their own apps over standard TOTP, which I guess could be seen as a sort of proprietary passkey. Shopify, Google, Microsoft, and more, they all want you to download their app for MFA, instead of using a very open format.

As someone who works in IT, I just can't even imagine myself doing this. I have probably around 60 codes in my Aegis, how would it look if I had just a quarter of those in apps instead?

But the main issue I have with passkeys is the simple issue of backups. I can backup my Aegis keys, I can't backup an app, or a hw passkey. I have to get a second one, and keep signing for it or something, not sure of the details, I just know it would be a major hassle. And there is no way I'm trusting a little usb device to not break.

Right now I see no compelling reason to switch from regular OTP codes, change my mind.

Gander5739

5 days ago

> Right now I see no compelling reason to switch from regular OTP codes. Change my mind.

The phishing potential?

INTPenis

5 days ago

I completely misunderstood passkeys.

tennysont

5 days ago

"Is not a trap" does not follow from "Is currently good".

A defining feature of traps is that they start out good.

There are a lot of good points in this article, but it fundamentally missed the point of the word trap. The most it said on that topic is:

  > If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.

Which is a statement about the near future. There is room for a conversation about the long term, but this article is not a part of that conversation.

5 days ago

They're better than passwords but just as annoying when I have to sign into Outlook every 5 days

5 days ago

Syncable passkeys are a thing which the OP addressed. Apple, Bitwarden, and other password managers all implement syncable passkeys. In fact, I just did an upgrade of my iPhone 15 Pro Max to an 18 Pro Max and all of my passkeys came along with the upgrade.

TrueDuality

5 days ago

I don't think it's appropriately addressed. The apple ecosystem has really good syncing between devices but only when they share an iCloud account. What happens when your work mac isn't permitted to use your personal account? What happens when your company issued password manager and your personal one fights? What happens when your company issued device is an Apple device AND you have to use a mandatory password manager from the company?

The problem to me is that passkeys assume the user owns the device and CAN choose to make a single store authoritative for their credentials. The only professional environments I've encountered that haven't/wouldn't hit this issue are ones small enough that they don't really have device or security governance in place which you can't use as a secure reference baseline.

fodkodrasz

5 days ago

you have the QR code based handshake thingie, supported by apple and windows 11 at least.

edoceo

5 days ago

Can they go from the 18 Pro Max to a Windows 11 device? Or to an Android device? Genuinely curious about the portability.

jeroenhd

5 days ago

I don't think Apple bothered to implement passkey support in their Windows iCloud password implementation yet.

You can log in by scanning a QR code with your phone, though.

Or you can use a different passkey provider that does work cross-platform. You don't have to use the one built into your phone.

johanyc

5 days ago

Yes. I use 1password and all those platforms are supported.

bemtevi

4 days ago

What if I don't want to use a phone any more and just use Linux without a password manager?

MisterMunchkin

5 days ago

I absolutely love them now that I have a Mac. They're shared between my phone and my Mac automatically so I can just sign in to anything with my fingerprint.

Passwords just suck. If we're all going to use password managers anyway, what is the point? Might as well use a randomly generated passkey.

MetroWind

4 days ago

> The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing

Sorry but this is the whole problem with passkey: you are forced to rely on a 3rd party to take care of your credientials, on their computers, with their software. This is like a text book example of a trap: someone set up something that looks harmless/invisible, you walk into it, and that someone now has some leverage over you.

LCRVYSB

The Substack blog post focuses on "control", specifically the control that users might sacrifice by using passkeys:

"What's important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys. "

"With passwords, you can choose where to write them down; with authenticator apps, you can decide for yourself which ones to use (they're pretty interchangeable); and with physical security keys you can hand them to your colleague if you really trust them."

https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-...

According to the Substack post, passkeys, per the specification, carry the potential for requiring specific hardware or software

Whether any company is using them this way yet is not the point

"If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now."

This is addressed in the Substack post:

"This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch - perhaps not all at once, perhaps just for ten thousand users at a time so as not to cause a fuss - and start rejecting non-attested passkeys."

The point is that a website _could_ do that. It's possible and there's a pathway set up to do it via the specification

The first step is getting users, a majority of them, to switch to passkeys

The "security researcher" does not say (a) this cannot happen, he claims (b) it will not happen

The (b) response conveniently sidesteps the point

When HN readers see the term "attestation" they might think of Google's scheme for remote attestation

1781305131 | Google's new remote attestation scheme is as terrible as old scheme | https://pluralistic.net/2026/06/12/compelled-speech/ | https://news.ycombinator.com/item?id=48510372 | 0 comments

1783608717 | Google's new remote attestation scheme is every bit as terrible as its old one | https://www.eff.org/deeplinks/2026/07/googles-new-remote-att... | https://news.ycombinator.com/item?id=48846883 | 1 comment

"Attestation Isn't What You Think It Is"

"YubiKeys are the authenticators that do attestation."

Of course Yubico recommends against attestation

https://developers.yubico.com/Passkeys/Passkey_relying_party...

However whether any website is requiring attestation via passkeys yet, or recommending it, is not the point

The point is that this possibility is contemplated in the specification; using passkeys opens the door to the possibility of requiring attestation

There is nothing inherently wrong with attestation

What matters is who would be doing it, e.g., Big Tech, and how they might use it to further their goals

Alas, that's outside the control of the user

That is the point: loss of control

https://fidoalliance.org/metadata/

"MDS acts as a global registry of passkey capabilities and equips your FIDO server with the intelligence needed to make data-driven decisions about which devices are allowed to access your systems."

Some users may be concerned about websites requiring them to use particular hardware and/or software

There is nothing inherently wrong with MDS

But it could be used to exclude users with "unacceptable" computers and/or "unacceptable" software

Will it. Who knows. That's not the point

"TOTP Is a Step Backwards"

"A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com. "

"This is the problem that passkeys solve."

This seems like a relatively small step; tradeoff for TOTP users seems worth it

tamimio

5 days ago

>here’s why you should use XYZ!!

Few weeks later

>let me tell you why you should NOT use XYZ!!

5 days ago

Google and other services like PayPal make Passkeys default if you generated one.

Now they expect you to always use them to login on all devices.

I had to remove my passkey from one device for these services because i also use a PasswordManager and I do not trust my local chrome installation to just manage my passkey.

I use Brave and 1Password. Clicking the Use Passkey button typically results in some Chrome Bluetooth permission dialog rather than accessing my PassKeys.

I tried to look into this once or twice with no success.

I suspect macOS is at fault. Apple does not seem to care about getting basic functionality right.

To this day Universal Clipboard between the MacBook and my iPhone does not work half of the time.

5 days ago

I'm sure they exist but I have yet to come across a service that both removes the ability to also use a password when you register a passkey and also has no other recovery methods if your passkey (and/or password) become unknown or unavailable to you

In theory if I locked down my Apple account with the advanced protection features that are optional, I could lock myself out, but it would be on me to save recovery codes/secondary passkeys/etc during enrollment in those optional configurations

Otherwise, I'd walk into the Apple Store and they'd be able to get me back in my account if I didn't have some alternate method to get in

HotGarbage

5 days ago

You have one Apple device that gets lost. You buy another and try to log in. Apple expects you to approve the login with the lost device. What now?

dcrazy

5 days ago

You do the acccount recovery flow. Options include providing your recovery key or proving your identity to Apple customer support. Do you really think Apple did not account for this?

HotGarbage

5 days ago

What recovery key? I must have lost mine. ID verification? I never provided my ID to Apple when creating my account.

dcrazy

5 days ago

Account recovery: https://support.apple.com/en-us/118574

Recovery key: https://support.apple.com/en-us/109345

dcrazy

5 days ago

Why would they be lost? They are synced to iCloud Keychain, which is E2E encrypted.

unethical_ban

5 days ago

It's just not a replacement for TOTP and password entirely. It's a shortcut, a super-cookie that is more secure. If I lose the device that has my passkey, I need a way to access my account from another device.

One might say "just use a password/credentials manager", but all these passkey prompts don't emphasize that you should use one that is not tied to hardware, or that you should backup your passkey to a thumb drive, or anything like that.

Same reason I hate TOTP that is tied to a device. If you require me to have proprietary 2FA apps on my phone to login to your account, I don't use 2FA. Looking at you, Steam.

5 days ago

This:

> Thankfully someone with some sense

Cannot be asserted with this:

> I saw that post title and didn't even bother to read it.

user

5 days ago

[deleted]

chaps

5 days ago

Why didn't you bother to read it but still think they have no sense?

alterom

5 days ago

Because, apparently, passkey evangelists are a cult.

The spec requires passwords to still be an option, they say, so there's nothing to see here, move along — and avert their eyes should an inconvenient argument come their way.

Because, see, we all know that specs are ironclad, never change, and are always fully implemented.

Also, putting all your eggs, ahem, passkeys into one cloud basket (as this article recommends) to "move around" is surely the most best solution better than passwords.

Because we can always trust the cloud, right? Not like it's somebody else's computer or anything, that they can instruct to not do what you tell it.

Anyway, none of the passkey lovers ever answered me what to do if my computer and cell phone ever get stolen again when I'm traveling abroad in the Brave New Passkey World.

The best answer I got was carry a yubikey with me at all times.

One more thing to worry about losing, yay. Much convenience, very security, wow.

If there are any new developments on that front, would love to hear them.

blackcatsec

5 days ago

Because I too understand passkey attestation and have written code to do exactly that and have worked in multiple enterprises where we've done a mass Yubikey rollout across thousands of people. So I've got a pretty solid understanding of passkeys, yubikeys, and attestation. As well as I don't read headlines of people claiming it's "tracking you".

alterom

5 days ago

Yay, finally an expert.

Can you help me figure out some things?

1. One time when I was abroad in Poland, a thief walked into my room at night and stole my wallet, phone, and laptop.

(The thief was eventually caught 6 months later, but that's another story).

Question: what to do in that case if I were using passkeys?

Is there a solution that doesn't require trusting a cloud provider?

2. Currently passkeys are offered as an alternative to passwords. What are the mechanisms that require passwords to be available as well?

I.e. what stops my bank from simply giving me a passkey at a branch and offering no other option?

3. Clouds are currently the easiest way to use passkeys. Last time I checked, you were locked into that cloud, but things move fast.

What ensures the ability to move the keys out of the cloud?

And what do I need to do to have my own "cloud" like that?

4. What protection does the passkey ecosystem offer for physical threat to the user?

With passwords, there's no way for anyone to know which Hacker News accounts are mine, or whether I still have access to them. I don't remember has plausible deniability (who hasn't ever forgotten a password?).

With passkeys, getting detained with your device means surrendering all your passwords, to my understanding.

What am I missing?

Thanks!