Top
Best
New

Posted by ashergill 10/28/2025

Passkeys: They're not perfect but they're getting better(www.ncsc.gov.uk)
55 points | 136 comments
ajnin 10/28/2025|
> websites which [...] also want to know how the passkey is being handled by the user’s device to keep their accounts safe

This is exactly where passkeys go too far. "to keep their accounts safe" is always the excuse used to reduce the freedoms of users. Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable. The boundary of control of a website used to stop at the interface between the site and the user. Now that boundary will extend to the devices. The idea of property and ownership is attacked again. The device is not something the user owns and has full control over but something that is a gateway to access content controlled by the big Internet companies.

Knowing this, how long until Netflix, Disney other content providers (sorry I don't know which ones are popular right now) demand use of a passkey originating form a device with a Trusted Platform (aka Untrusted User) Module ? This is part of a long plan initiated years ago with Windows TPM requirements, Microsoft account requirements. The gap between closed and open platforms will widen and the path is clearly to apply the Smartphone model where everything is closed, controlled, DRM'd, to other computers. We're lucky the IBM PC architecture was an open one but the war on that is on.

throwawayffffas 10/29/2025||
Yep the whole tpm thing and the device constrained nature they have envisioned is the major drawback.

But no they have to live in their secured enclave or on a dongle so that you can't copy them between devices because nothing ever happened to a device.

As if the rest of the users system is compromised the user can't be tricked into providing access to their account.

And no one ever "recovered" someone else's account.

The main benefit of passkeys is that they are keys you don't have to send them over the wire. The main risk of having them on disk encrypted purely in software is that a compromised system can lead to the keys getting stolen.

Their trusted platform bulshit doesn't really escape that threat though, instead of stealing your keys the attacking malware can just get access to your service and maybe even enroll their own key.

If you tried to login to a website and you got two requests to allow the use of your key one after the other would you really have the wherewithal to say no wait a second I just gave permission for that key to be used, the second request is obviously from malware on this computer that's trying to gain access to my account.

That's ignoring that the malware can just read everything you are reading.

The whole tpm obsession is security theater on top of a power play

m-p-3 10/29/2025||
> But no they have to live in their secured enclave or on a dongle so that you can't copy them between devices because nothing ever happened to a device.

I'm actually fine with this. It's like how SSH private keys are supposed to be handled: generated on the device, and never supposed to leave it.

The proper way of doing Passkeys is to have several Passkeys enrolled in your account, so that you always have a trusted device to access your services. Now, if the service doesn't allow multiple Passkeys per account that IS a problem.

stavros 10/29/2025|||
I've seen this argument many times, but I don't understand it. Can you explain a scenario where this would be an issue? So, Netflix makes me log in with a passkey that comes from their own hardware, instead of my password manager. What's the danger there, beyond the fact that this seems to me extremely unworkable because I'd just never sign in?
array_key_first 10/29/2025||
The danger is that you now can no longer use netflix without they're approved hardware? Of course, that's essentially already the case with netflix, but this becomes dicey when services that actually matter take this approach.

And then suddenly you're debanked.

stavros 10/29/2025||
No, we're talking about logins, not usage. Can someone explain to me a case where logging in only with an approved authenticator would be problematic?
geonineties 10/29/2025||
How exactly are you going to use a service that requires login if the login requires an authorized device you don't have?
stavros 10/29/2025||
OK, so what's the scenario? Netflix wants to make me not use their service? Surely there are easier ways to do that than to make a new auth standard?
throwawayffffas 10/29/2025||
It's not really Netflix. Its Microsoft, Apple and Google.

So say goodbye to using teams on Linux. Using Microsoft365 on any hardware that is not Microsoft approved.

Or logging in to your bank without an iPhone or an android. We will surely complain but the bank will say that we only support secure devices and that means iPhones and Android, and how come you are making a big deal about it just buy one of these two everyone else has one.

joshuamorton 10/29/2025||
> Or logging in to your bank without an iPhone or an android.

This is already possible (and common!) many banking apps, for better or worse, use device attestation features that require varyingly official copies of android. Were you already complaining about this?

ajnin 10/29/2025|||
> Were you already complaining about this?

Yes, "we" were, definitely. I already can't freely choose the OS that I have installed on my phone because I'm limited in the apps that I can install. For example many government ID and banking apps will refuse to work on GrapheneOS even though that OS is security-focused and will probably keep you safer than your regular Chinese Android flavor. But it's not sanctioned by a big international corporation so it's a no. Is your argument that we shouldn't complain since it is already happening somewhere ?

What's an "official" copy of Android ? AOSP is supposed to be open-source. "Official" means controlled by a multinational corporation. I'm very puzzled that the reaction to these entities gaining even more power, outside of democratic control, is met with a "oh it may me worse, it may be not" type of reaction.

Would you be ok if for example your government's website to pay your taxes mandated a device with attestation knowing you can only get one from Google, Apple or Microsoft ?

joshuamorton 10/30/2025||
> Yes, "we" were, definitely.

I am not unaware of the potential dangers of device attestation.

> Would you be ok if for example your government's website to pay your taxes mandated a device with attestation knowing you can only get one from Google, Apple or Microsoft ?

My point is this is already possible today. A lot of apps do it. An open attestation API means that, at least theoretically, systems not owned by one of those three providers could be used. Today you get, functionally, a signal of "this is blessed android or not". An alternative world where the device attests "I am grapheneOS" and it is up to the service to accept that attestation or not is strictly better than the ability today.

throwawayffffas 10/29/2025|||
It's definitely worse. Banking credentials are stolen the old fashion way, phishing.
joshuamorton 10/29/2025||
I'm not sure what your point is here. How credentials are stolen today is irrelevant to the fact that today, right now, at this very moment, banks can and do already do the thing you're worried will be possible only due to the prevalence of passkeys.
throwawayffffas 10/29/2025||
Oh my point is that their device attestation thing is security theater.

It's clearly just for getting that iso certification.

It's a power play by the platform vendors.

The vendors are literally saying:

We now have this "security" feature and banks have to use it to be compliant and it only works on our platforms, so I guess you have to use our platform unless you want to be unbanked.

joshuamorton 10/29/2025||
I mean, I would agree that it's not a particularly useful thing for consumer-phone-bank usecases, but that doesn't mean the feature is bad (or harmful).

Just to be clear, no one is saying

> banks have to use it to be compliant

nor are they saying

> it only works on our platforms

As far as I know, if systems were to use attestation it would be in a lot of senses more open than what attestation is available today (in the sense that more devices could use it). But also I don't think anyone who works on passkeys is saying banks need to support FIDO attestation to be "compliant".

petre 10/29/2025|||
> Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable.

On the contrary, their operators can decide whatever they like, but I won't be visiting them if they go the passkeys route. I can live w/o Netflix or Disney just fine.

Your PII will leak off their platform anyway.

ajnin 10/29/2025||
You'll also have to live without banking, government ID ... The "I don't need those services" rhetoric only goes so far.
JohnFen 10/29/2025||
At least where I live, there are no actually important services that can't be done in person.
throw-the-towel 10/29/2025||
Yet.
DANmode 10/31/2025||
How do you keep out multi-device USB HSM users?

Arbitrarily?

I’ll die on that hill.

nabla9 10/28/2025||
Losing your device and not having any passwords is like losing your fingerprints.

>Device loss scenarios

>Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.

>Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.

0cf8612b2e1e 10/28/2025||
Also requires the device allows backup of passkeys. The infamous post where keepass was threatened if they were to continue to allow users to backup their own keys.
spiffytech 10/28/2025|||
I hadn't heard this story. Source: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
stavros 10/29/2025|||
The person there requested that KeePassXC don't let users export their keys in plaintext, which seems reasonable. He asked that the software encrypt the keys with a user-selected password before exporting, so someone stealing the files wouldn't have the keys to literally all of the user's sites. That doesn't seem unreasonable to me.
throwawayffffas 10/29/2025||
Not really dude, if I can't export in plaintext I can't pick the encryption I have to use whatever keepassxc will do. I can't pipe it to gpg and encrypt it with my key.

And on the other hand I can only load them to another keepass instance I can't switch credential managers.

If you are worried your system is running malware that will steal your plaintext keys, well bad news they can steal the encrypted keys and keylog your password.

joshuamorton 10/29/2025||
> If you are worried your system is running malware that will steal your plaintext keys

No, I'm not worried about this since I do not and will not copy my keys.

I'm worried about my friends or family using the most secure options possible (passkeys) and still getting phished because they paste their plaintext secrets into a scam site.

throwawayffffas 10/29/2025||
Even without copyable keys, if your friends and family can be tricked into pasting their plain text keys into a scam site, they can be tricked into pasting their encrypted keys and their associated password to a scam site.

The point of encryption at rest is to protect your data if your device is accessed by a third party. Not from user action.

joshuamorton 10/29/2025||
> Even without copyable keys, if your friends and family can be tricked into pasting their plain text keys into a scam site, they can be tricked into pasting their encrypted keys and their associated password to a scam site.

The point is that data shouldn't really be copyable, but a backup should at least be encrypted.

Ideally you don't have or need a key transfer mechanism, because sites have the ability to register multiple keys and you add or remove devices by adding or removing new keys, and you recover a backup to the same passkey-manager.

"Please upload the backup of your password manager and enter the root password" is not a thing you should ever do, and reasonable users, even technically incompetent ones understand that. The only people who want that behavior to be possible are weird power users whose desire makes it easier for anyone who uses such a password-manager to be phished.

Like, I've had this conversation before on this site, and my personal rule of "I should never copy a private key, and I should certainly never copy a private key between devices or onto a cloud" remains something I'm confident in. If I need a private key used across devices, I can trust it to a key-management scheme like the ones built into Signal or the various passkey managers I use. I don't want to manually copy my signal cypher-data between devices either!

throwawayffffas 10/29/2025||
> I don't want to manually copy my signal cypher-data between devices either!

Yes you. Others do. Whenever I switch laptops the first thing to do is copy over all ssh keys. I am not going to roll a new key and add it to 100 servers.

A couple of years back I switched password managers, I didn't go over 1000 sites and changed all my passwords, my password manager exported a plaintext file and I had it imported in the other after a small transformation step.

> "Please upload the backup of your password manager and enter the root password" is not a thing you should ever do, and reasonable users, even technically incompetent ones understand that.

No they don't and if they did they would also understand not to upload their plaintext credentials.

Security for the lowest denominator cannot be used as an excuse for locked down computing for everyone or at least it shouldn't. At some point we have to put on our big boy/girl pants and know the implications of what we are doing.

joshuamorton 10/29/2025||
> A couple of years back I switched password managers, I didn't go over 1000 sites and changed all my passwords, my password manager exported a plaintext file and I had it imported in the other after a small transformation step.

And, modulo the "plaintext" part, I think this is a reasonable usecase. It's equivalent to the "backup" case. I transfer an encrypted blob between devices and decrypt it locally is reasonable.

> No they don't and if they did they would also understand not to upload their plaintext credentials.

Except that you have already stated that you have done exactly this, and you claim to know what you're doing!

throwawayffffas 10/29/2025||
When did I say I uploaded my plaintext credentials anywhere? Do you mean the password manager? That's local and open source.
burnte 10/28/2025||
Just not having the right device with you is crippling. IMO Passkeys need more work. I'd really like to see accounts support multiple passkeys. I'd prefer biometrics that are device independent. I just don't like the idea of replacing something someone can steal (a password) with something else someone can steal (a phone).
tzs 10/29/2025|||
> I'd really like to see accounts support multiple passkeys

Most accounts seem to. Personally, I think I've only found one or two out of around 25 that I've added passkeys to that would not let me add more.

torstenvl 10/28/2025|||
Would be nice, but biometrics have also been systematically made less secure. Apple, for example, no longer sells a phone with Touch ID.
foobazgt 10/28/2025|||
At first I read this as "Apple doesn't implement Touch ID, because they found it to be insecure", which really confused me. Was that the intent?

On second reading, I'm thinking this might mean, "since Apple only implements Face ID, biometrics on Apple devices is less secure", which makes more sense (to me).

torstenvl 10/28/2025|||
Yeah, the latter. All kinds of reports of siblings (including fraternal twins and non-twins) being able to unlock each others phones.

https://duckduckgo.com/?origin=funnel_home_google&t=h_&q=fac...

Fingerprints are much more non-deterministic and therefore more secure.

throwawayffffas 10/29/2025|||
Aren't fingerprints obsolete as biometrics? Last I remembered fingerprints can be lifted if high resolution pictures. I.e. any picture where your thumb is visible.
burnte 10/29/2025|||
Vendors not using biometrics well doesn't mean biometrics are insecure. Apple not selling touch ID CERTAINLY isn't evidence of the security of biometrics.
torstenvl 10/29/2025||
If nearly all biometrics systems currently on the market are insecure, then it is fair to say biometrics have been made insecure.

Of devices currently sold, the only secure biometrics I'm aware of are on iPad mini/Air; Google Pixel; Honor Magic; and possibly Samsung Galaxy S21 and newer.

supermatt 10/29/2025||
The problem with passkeys is that device/OS and browser vendors (or more specifically: Apple, Google and Microsoft) are trying to use it as an excuse to lock in users.

There is no reason a passkey can’t be portable - even the so called “device bound” credentials these vendors are claiming prevent export are actually implemented as credentials synchronised throughout their own ecosystems - i.e multi device.

NOTHING in the FIDO2/WebAuthn spec forbids user controlled portability.

It’s just bigtech trying to make it harder to leave their ecosystems - and when passkeys become widely adopted you won’t be able to log into those sites/apps without some form of recovery on a case by case basis should you decide to switch from Apple to android, windows to Mac, etc.

runningmike 10/28/2025||
“Passkeys are the future of authentication” …this is not the future I hope….When Google, Microsoft and a lot of other B*G-Tech companies promote Passkeys, you know it is not done to protect your security and privacy.

Nice read https://techrights.org/n/2025/05/02/Passkeys_Are_Vendor_Lock...

varbhat 10/28/2025||
I agree. I use Bitwarden on my Samsung Android phone and also on my Linux desktop. Bitwarden currently supports passkeys on almost all the apps on my android including firefox. The same passkeys which i used to login on my phone can be used on my Linux desktop where i use Firefox with Bitwarden extension. What's now possible was not even possible at the start of this year. I haven't switched everything to passkeys but i can see it as an alternative to passwords now(passwords really shines in some areas too).

I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.

josephcsible 10/28/2025||
> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.

Here's an Okta employee threatening to use the attestation (anti)feature of passkeys to block open-source implementations, because they allow you to export your passkeys: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

varjolintu 10/29/2025|||
FYI: If you export your Bitwarden vault as plain JSON, passkeys are included in plain-text too. So, it works similar to KeePassXC.
FreakLegion 10/28/2025||||
Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.
jauntywundrkind 10/29/2025|||
Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC:

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

Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like.

The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedbac...

Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608

FreakLegion 10/29/2025||
Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.)

We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.

commandersaki 10/29/2025||
Apple does precisely this for Apple account, you need to have a hardware attested passkey implementation to authenticate using passkey.

Edit: forgot to add Apple account

FreakLegion 10/29/2025|||
To your edit: I suppose this is strictly true, but it's relevant that Apple's own devices satisfy the attested hardware requirement. These are the same devices you need to have a full-fledged Apple account in the first place. That's more Apple doing Apple things than anything to do with passkeys, but it is indeed an example of not being able to use KeyPassXC. Will there be more than epsilon cases like that? I still don't think so, for what seem like obvious market reasons.
commandersaki 11/1/2025||
Will there be more than epsilon cases like that?

I anticipate banks, enterprise sso login, etc. doing this.

FreakLegion 10/29/2025|||
To authenticate to what? I have a few dozen people using passkeys on macOS without attestation, but I'll admit none of them are logging into "Apple".
josephcsible 10/28/2025|||
The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
FreakLegion 10/28/2025||
Sorry, to clarify: Okta is not for our purposes a relying party and won't do anything to force attestation on relying parties. The second bit of what he wrote is ambiguous, but charitably, could simply mean "I used to argue against requiring attestation, but now I'm not sure". Which is fine, since he has absolutely no pull when it comes to how Okta's product works (and to be fair, I don't think he implied otherwise or even mentioned Okta).
gowld 10/28/2025||||
> because they allow you to export your passkeys

because they allow you to export your passkeys in plaintext, for easy stealing.

"Information wants to be free" should not apply to passwords!

josephcsible 10/28/2025||
But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.
wbl 10/28/2025|||
That's the whole point of this exercise. If export is possible it's not secure against local compromise in the way that's needed.
josephcsible 10/28/2025|||
The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
ngrilly 10/28/2025|||
That’s why most banks ask you to approve transactions with an explicit reauthentication.
josephcsible 10/28/2025||
Then the malware will just wait until you want to do something legitimate that needs that, and then swap it out for its own thing.
wbl 10/28/2025|||
But it can't maintain that compromise. That's important.
tzs 10/29/2025||||
That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already.

For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.

AlexandrB 10/28/2025|||
Needed for whom? As others have said, without export it's a recipe for vendor lock-in.
gowld 10/28/2025||
lock-in to which vendor?

Passkeys support transfer to any vendor you want.

AlexandrB 10/28/2025|||
Can you send some documentation on how? For example, I tried googling for transferring a passkey out of popular systems and it doesn't seem possible[1][2] other than through JSON export[3] which is what some sites want to block as I understand.

[1] https://old.reddit.com/r/Bitwarden/comments/1efs5d2/how_can_...

[2] https://old.reddit.com/r/Bitwarden/comments/1di8nbz/import_p...

[3] https://news.ycombinator.com/item?id=44454106

secabeen 10/28/2025||
I don't think you're going to find it. The main vendors are hostile to this workflow. I get why, any flow that can exist to export passkeys can be used by hostile actors to walk a 75-year old millionaire grandma through handing over $$$. I think however that that's just a risk we have to make the bank and brokerages accept. It's not a problem with a technical solution.
wbl 10/28/2025||
Why is it more important than protecting users? They've already added a way to share them securely.
eikenberry 10/28/2025||
Wasn't the discussion you responded to about how they currently can't be shared and that the vendors don't want them to be shared as it breaks their desired lock-in?
wbl 10/29/2025||
They can be shared just not insecurely. That's why they are working on a spec.
amenhotep 10/28/2025||||
I want to transfer them to a vendor that will let me export them in plain text.
josephcsible 10/28/2025|||
Is it really "any" vendor, or is it just the big ones? Can you transfer your Apple passkeys to KeePassXC?
secabeen 10/28/2025|||
I can't even find documentation on how to do the simplest transfer, from Apple iCloud Keychain to Google Chrome or vice versa.
tzs 10/29/2025|||
Not yet. Apple supports export using FIDO's Credential Exchange standard. KeePassXC is working on adding that.
abdullahkhalids 10/28/2025||
So the same passkey is being used on multiple devices, rather than different devices (actually applications) having distinct passkeys.

Doesn't that defeat one of the centrals aims of passkeys? In what ways is your setup different than random passwords in bitwarden - what's the additional security?

greenicon 10/28/2025|||
Passkeys cannot be phished.

Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.

ianburrell 10/28/2025|||
Another is that passkeys are single login and sites don’t use 2FA. Not having to get out TOTP or receive SMS is worth it.

Basically, any site that does 2FA should take passkeys.

eviks 10/29/2025||
You can store 2fa in a password manager except for the dumb sms-bases ones, but that's still an extra step
eviks 10/29/2025|||
Password autofill also provides that protection as it won't match on phishing domain
temp0826 10/28/2025|||
The password manager has become the device (and offers some assurance if the device is lost, as you can log into the manager on another device). I agree definitely isn't the original vision of passkeys (having a different passkey on every device, stored in separate password databases?), but it makes more sense for my cases.
jauntywundrkind 10/28/2025||
Nicely timed on the one year anniversary of FIDI Alliance's Credential Exchange Protocol and Credential Exchange Format. https://fidoalliance.org/fido-alliance-publishes-new-specifi... https://news.ycombinator.com/item?id=41847787

But afaik you still can't move Passkeys from Chrome or Safari to any other credential manager.

I was vaguely under the impression that there was a ton of push-back again import/export flows in general, that the CEP was going to be the only supported path. And it requires that your Credentials Manager have a public endpoint to send your credentials to. Which doesn't force but radically ups the challenge for individuals to self host or manage things themselves, will drive Passkeys to remain service provided only.

With governments upping their right to snoop, immoral intercept, it's hard to have too much hope that Passkeys can remain trustable & respectable. If the UK passes a law saying they can access all your keys, the odds are not in your favor that Google is going to make a Signal like stand & tell the UK to buzz off. It's unfortunate that these giant massive enterprises are so big are so many products all in one, because if there was a healthy Chrome business not tied to thousands of other profit lines, maybe Chrome would dare have some backbone & tell their majesty to go stick it where the sun don't shine. But these companies are so big that even the most immoral outrageous ridiculous laws end up being accepted. Passkeys seems like a huge painted target; maybe the next 15-20 years go by with no one trying to get in the cookie jar, but it seems inevitable that the moral rot and illegitimacy of governments will stoop down to making this good idea untenable & a joke, in a long enough time scale. Especially with the service-provider-only ecosystem that's being engineered and imposed here.

hollow-moe 10/29/2025||
Websites can choose to not accept your passkey manager ("accept" not "block" since it will obviously be enforced as whitelist). What could possibly go wrong ? If only there was a similar example with an existing system like TOTP and a big company like Steam.......... Link unrelated https://github.com/keepassxreboot/keepassxc/discussions/9591 Eventually get debanked and go live in the woods ig
djoldman 10/28/2025||
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.

> Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.

The benefit to the user of a passkey is that they don't have to remember passwords ("what you have" and not "what you know"). But if you lose what you have, you're screwed. There's no straightforward way to mitigate this.

Proposed solutions I've seen just add an extra layer of "what you know," but this just changes the security back to "what you know" if it supersedes the passkey.

JohnFen 10/28/2025||
I'm glad that someone is at least seriously talking about these problems. A couple of them are serious enough to make passkeys a real pain in the butt for me. A big enough one that the whole scheme is a nonstarter.
g-clef 10/28/2025|
Until passkeys can pass the test of "my non-technical friends and family don't call me for help about them", passkeys aren't ready. Vendors keep making assumptions about how users behave which are not safe assumptions, and that keeps blowing up the interactions of non-technical users. (I'm sure there's an "assumptions developers make about user accounts" blog out there somewhere.)

For example, my family has had to call me for help on the interaction between passkeys on Apple & Amazon multiple times. They have a shared Amazon account, which neither Amazon nor Apple seem to like. The first problem came when they didn't even know they'd been moved to passkeys - there was a popup that one of them didn't understand, they clicked OK to get it to go away, and suddenly the other partner can't log in, and neither of them can figure out how to log into Prime Video on their AppleTV. Another time one of them got "nudged" to add a fingerprint to the account, again freezing out the other person.

Until that nonsense stops happening, Passkeys aren't ready.

stavros 10/29/2025|
By that metric, passwords are even less ready, as I seem to always have to field calls for passwords getting stolen or compromised or accounts getting phished. I guess we're back to faxing ID.
rekabis 10/29/2025||
I have a non-technical father with dementia, and passwords+TOTP are almost frictionless for him, with minor exceptions. We are able to share around passwords and TOTP codes without any problems so I can properly monitor his online activities to keep him out of trouble. He’s a cranky old guy with almost zero trust, so having to input all that stuff satisfies him that security is being employed.

Passcodes just freak him out.

stavros 10/29/2025||
I think Github is basically the only good passkey implementation right now. The ideal flow should be:

* Click login button

* Window pops up asking you which passkey you want to use, you click the one you want

* You're in

Anything on top of that is just added friction, and I haven't seen many sites get it right.

More comments...