Therefore, the author's scenario that sites will wait until most of their users are using attested passkeys and then "flip the switch and start rejecting non-attested passkeys" isn't very plausible.
Attestation is certainly a stain on the WebAuthn spec, and it would have been better if Chrome and Firefox didn't support attestation (unless perhaps the browser is enrolled in enterprise management), but this blog post is presenting a hypothetical and unlikely scenario. That's not a good enough reason to recommend TOTP instead, given that TOTP is vulnerable to phishing and passkeys aren't.
If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out, and maybe then the recommendation to use passkeys should be revisited. But until that happens, don't tell people not to use passkeys.
Of course it is, the site will reject the passkey and require you to create one that is attested.
> Are Netflix and Twitter currently requesting attestation when people register passkeys, and rejecting the registration if the user declines the permission prompt?
They could start tomorrow.
> a hypothetical and unlikely scenario.
You have not been paying attention, that scenario is where this whole thing is building towards.
> If consumer-facing sites start requesting attestation when registering passkeys, they deserve to be vigorously called out
It's going to be the banks first.
Why called out, it's all for your safety, to make sure you are not using an insecure client that might leak your data.
To suggest that people should stop using Passkeys over this is throwing the baby out with the bathwater. All of these features of Passkeys are appropriate in a given context. The only concern is where a service that might not need/justify "high security" Passkeys starts demanding them anyway, and no-one is forcing you to use said service in that case.
Passkeys exist now and there's no taking them back. However, even if they did not, the government might well just develop its own authentication system and require that it be used under policies that require age verification for social media, for example. Hell, they might end up doing that anyway, and that would be no different. If the government wants to force tracking/verification on certain websites, it won't simply be something they walk away from if Passkeys don't exist. You can only fight this with your vote and by not using those services once they implement such controls.
The main problem in my mind is on the side of the vendors, attestation, secure hardware, etc is all an excuse to lock you in to their device/ecosystem.
Like how everyone stopped using Google/Gmail, Facebook/Instagram and Windows/Office365 and flocked to alternatives?
Let's flip your suggestion. What if someone says if you need "high security" build a competing service that enforces it, no one is forcing you to use a "low security" service ?
My point was not about getting critical mass, it's that the service can already do anything they like to lock people into whatever they want and gatekeep their service. They can do it with Passkeys, or they can do it with a proprietary alternative and if they're big enough, they'll get away with it. Neither of us can sway them at all - I wasn't saying they should do this, only that they can.
Blaming Passkeys is aiming at the wrong target. Passkeys rightly offer features that have valid use-cases, even the attestation in the right context. Can they be abused? Probably, but so can just about anything. Passkeys do, on the other hand, offer some real tangible benefits that other mainstream solutions do not.
Let the usecases that need passkeys use it.
Why can't there be a parallel standard with similar features that doesn't have the parts that can potentially be abused. If the difference between abuse and non-abuse is a vague promise and the good graces of corporate structures, it is better to err on the side of caution and demand solutions that make it impossible.
> The people don't care enough to bother, and that's fine - it's not your (or my) place to force other people to do anything.
Yeah it wasn't your place or anyone else's. How can you or I force anyone. Not sure why that even came up.
Debate is how we evolve new and alternate solutions. Handwaving by saying not your place or mine is not how we affect change if needed.
Why would that suddenly change in Netflix or some other company's favor at Apple's direct expense?
So you are now locked in to the apple ecosystem forever. You now need Apple to watch Netflix from your Samsung TV.
But man... I cannot tell you how many people don't even notice the walls of the garden. Besides Apple is in competition with some huge players, more than capable of offering "Done with Apple literally trapping you? Follow this link and we'll transfer your passkeys."
That ship has sailed a long time ago.
Most people still hanging to that part have already built a whole way of life around the Apple ecosystem and the boundaries and how to work around them have become second nature to them.
The iPhone is now near 20y old, the world also changed, most got enshitificated, and looking at kids and elderlies dealing with their iPhones and macs none of it "just works".
Looking at Japan, it was the bastion of iPhone predominance, but I'm the latest numbers 30+ yo gradually got off the train to move to android as their phone is just becoming another tool to them.
That's the whole point of the FIDO specs. This is now literally impossible to do. All the vendors are weirdly okay with this I believe it's because it cuts both ways.
They could start doing it tomorrow. They just have to flip the switch.
What’s your point?
As for the browser permission prompt: Firefox simply warns you that the site is "requesting extended information about your security key [sic] which may affect your privacy." [1] It does not make it at all clear to the user that what's really happening is that the website is gating acces behind a specific approved software stack. If I use a non-widely-used OS or device, what website is going to approve its attestation credentials?
[1] https://github.com/mozilla-firefox/firefox/blob/8e9ac3e12bba...
Would a website want you to have to use Apple Passwords to guarantee that the account you're creating is connected to an Apple account, and thus making it more likely that you're a real, non-anonymous human?
edit: Why not just require "Sign in with Apple/Google" if that's the goal?
"I'm different!" says this particular scorpion - yeah yeah, I don't believe you.
1. Many services have old users with passwords that predate password-strength meters (or their ill-conceived brethren: password complexity rules). The service provider knows these passwords keep falling, and the cost of having to deal with stolen accounts is very real: customer support calls, reimbursements and investigation. But I've rarely seen services that force users to upgrade their passwords (even though it's a very easy solution). Whenever I've offered doing this myself, it was always shut down (either immediately or 3 years down the line) by a myriad of seemingly unrelated stakeholders.
2. To go further than this, companies can also know for certain that some credentials have been leaked by looking at password breach aggregators like Have I been Pwned and forcing users with affected accounts to change their passwords. That too, is rarely done.
3. 2FA (with SMS or TOTP) has existed for ages now, yet very few major non-financial services have made 2FA mandatory by forcing you to register an authenticator app or a verified phone number[1].
4. Webauthn was available in Chrome and Firefox in 2018, and got pretty widespread support by 2020. The "Passkeys" brand was not a thing yet, but the basic functionality was there and both hardware and software support was quite solid. It still took several years for services to even start offering Webauthn to users, beyond small and limited trials. The rationale was simple: UX around Webauthn was still rough, syncing and transferring credentials were still unsolved and the worst part was "What do we even ask the user to do?". The broad concept of passkeys is extremely confusing, but the non-concept we had before was far more confusing. Supporting Webauthn back in 2020 would have given tremendous security benefits for power users who could have understood it and deal with the rougher UX back then, but nobody wanted to take the risk of regular users setting up a passkey, losing it and locking down their account.
5. Now that passkeys are being supported by more and more services, you still don't see them being pushed very hard. Passkeys are great for the service provider, since they just kill a big category of security incidents, but even then you're see pretty conservative adoption. And I've never seen a single service forcing you to use Passkeys.
My point in all these examples is that most companies are extremely conservative here. Forcing users to do something that might confuse them, break their account or frustrate them is risky, since you may lose a very real chunk of your customer base. Sometimes you have to do this, the costs from keeping the old way or the benefits or forcing the change have to be high enough to justify that. Think about how long it took for companies to drop support for IE6. The cost was high, but as long as it still had a sizable market share, it was hard to do. Google was probably the first major company to take steps towards killing IE6 support, and this was famously entirely bottom-up, and was done by engineers either hiding it from their bosses or tricking them[2].
With this trend. I personally find the scenario where non-copyable attested passkeys are forced on everyone unlikely. OP keeps mentioning Netflix, but streaming services are a rather special case, most service providers would get very little benefit from restricting users to an attested non-copyable passkey. Why would they risk all that friction for... nothing at all?
The more real risk with attestations (and we're already started seeing it) is that some services (namely banks) will use attestations to limit you to use their own shitty app instead of using a proper passkey.
---
[1] Keep in mind I'm only talking about companies that already had password-based accounts without 2FA. Companies that started out with a simple username and password are rarely forcing their users to add 2FA. The farthest they generally went is sending you an OTP code or link on a verified email address they already had, and this is usually only done for sensitive operations, a new browser and/or a suspicious location.
Email OTPs, notably, aren't 2FA by definition, since your Email address might be only password-protected, and at the worst case (and excruciatingly common) scenario it might be sharing exactly the same password as your service. Companies would love to have all their users using a stronger solution, so they can stop having to deal with all these pesky credential stuffing botnets, but not at the cost of losing a non-negligible portion of their customer base.
[2] https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6
1) There is this new entirely optional feature, but it's not relevant to you, so feel free to ignore it.
2) The feature is now active by default, but no worries, there is a simple button for you to opt-out.
3) The feature is active by default, but because we value our users, there is an option in the advanced settings to deactivate it.
4) Our data shows that 99.9% of users activated the feature, but if you belong to the handful of diehards who still refuse to use it (rolls eyes), you can use this obscure command line flag or about:config entry to turn it off
5) Managing opt-out infrastructure for the feature has significant maintenance and security cost that we feel, we can no longer justify. Therefore, effective in three months, the opt-out flags will stop working and the feature will become mandatory. According to our metrics, this will affect 0.0001% of our users, so no disruption is expected.
1. You can't use Firefox with our website (when I got this popup, I thought I had been transported back in time 20 years, but with Chrome substituted for IE).
2. You can't sign up for accounts with an e-mail from a "custom domain"
2a. I ran some tests; it's the domain itself, not the host, so e.g. foo@gmail.com is allowed but not a foo@somewhereelse.com, even if hosted by google).
2b. After a bit of back-and-forth with support: "No, we won't tell you the list of allowed domains, but gmail and hotmail both will work."
Incredible... if I ever get that I'll enjoy pointing out I've had my domain longer than gmail has existed.
My computers and devices feel less and less like tools under my control and doing my bidding, and more and more like something controlled by faraway tech companies, to do their bidding.
I do believe this is a policy failure and that a law should exist mandating cash acceptance “for all debts public and private”, but there is nearly zero chance of such a law ever passing in the US.
Even where it's "technically" possible, it's becoming more difficult. Some grocery stores around here don't staff traditional teller lanes at night, shrinking down to only self-checkout, which are card-only machines. To pay cash, you'll have to escalate to the roaming attendant (or at least, I assume they can find some way to accept cash for that transaction? I can't say I've tried)
The first time I was forced to use a passkey implemented within the vendor's app (3rd party password managers were not an option). I quickly closed that account.
The second time was an app that popped up a passkey opt-in in the middle of a bunch of transaction screens. I quickly realized the error, but there was no easy undo. The opt in was one green button in the middle of the screen. Turning it back off required digging through settings to find the security option to disable, and then confirm my choice multiple times. That process also signed out all my other devices.
The fact that companies are resorting to dark patterns and forced requirements, where my money is held hostage, should be pretty good evidence of how poorly the passkey rollout is going.
It gets even worse when you want to have separate passkeys, so that you have the possibility of knowing which one was compromised and doing a partial revocation: the cloud sync now requires every device to have access to every copy, so that you can individually enroll them during registration.
Yubikey of course suffers most from this, as their hardware tokens are physically incapable of any kind of sync, so a Yubikey passkey is very quickly a single-point-of-failure. They proposed[0] a system which would allow enrolling a "backup key" (which could then be safely locked in a vault, far away from day-to-day use), but with the various Big Tech companies pushing their own proprietary cloud-synced passkey implementations that of obviously went nowhere.
[0]: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Perhaps surprisingly, Windows has helped keep Passkeys from being "proprietary" lock-in because Microsoft no longer has users in a single ecosystem.
There is no dedicated auto-enrollment for "backup" keys, but most consumer sites make it very easy to enroll "backup" keys yourself.
Also, Passkeys don't have to be "online" to enroll additional keys. Each key is independent, enrolling is just generating new keys. The trouble is that web browsers generate lots of Passkeys (at least one per domain, at the very least) so if you in theory want to print them all and store them in a physical vault it might be a hefty book you are printing.
Cloud sync isn't required. Most users want it so that they don't have a single-point-of-failure.
As an implementation detail some Passkeys have a master key that is then used in some key derivation function (KDF) to generate the hundreds or thousands of individual passkeys (at least one per domain), and that's what most Yubikey passkey implementations need to do because Yubikeys weren't designed to store lots of keys, so it is devices like Yubikey that makes it seem like Passkeys are less independent than they really are.
Can you export it from there? My main gripe with passkeys in 1Password is that seemingly you can't export them, unless you export it to "someone else", which isn't clear if that someone can be just "you".
Want to dance? Yes | Maybe Later
> Addendum: I feel I have made a compelling case for passkeys in this article. And I haven’t even pointed out one of their best security features: they are (in most use cases) domain-bound, meaning they are resistant to what are called Man-In-The-Middle attacks.
"I made a compelling case... but didn't point out the most important security feature that motivated passkeys in the first place"
Honestly I don't think this post did make a compelling case. There's a lot of assuming bad faith on the part of the FIDO alliance, while completely missing that preventing MITM attacks was a key design feature. The FIDO alliance members deal with stolen accounts all the time, and passkeys largely solve that. Stealing accounts is almost always done with phishing or social engineering, and passkeys solve the former and reduce the surface for the latter.
The protections against MITM you mentioned is probably the biggest one, but the other one in the back of my mind is TOTP is a shared secret. So a compromise of the server side allows impersonation of users undetected, which can be a big problem. Maybe I'm over reacting because no company has ever lost a copy of it's database and they're all super secure. But, imagine trying to argue as a user I didn't do a thing when there is an audit log saying we challenged the user for TOTP and it was provided, was definitely the users fault.
Especially considering how easy it still is to do a SIM swap.
If you aren't talking from a US perspective, where are you that SIM swap is a low bar?
Heh.
Several months ago, I found myself in need of a new phone. I even had the means to do an orderly transition, with the old one still in hand and mostly working.
My mobile provider was an MVNO that was also my home ISP. I had enabled "enhanced security" to prevent ev0l hackerz from swapping my SIM without authorization. It turns out that this mode is so secure that it prevented me and the support staff from a normal upgrade procedure.
There were various glitches along the way, and a conversation with certain LLMs indicated that the SIM->eSIM disparity was also causing trouble, and with the online system's rejection of authentication I decided it was expedient to walk into their nearby storefront location.
It turns out that the salespeople in the storefronts are not really empowered in any technical way, except they were quite capable of changing my password without any reason, and wasting my time, so leaving the store empty-handed after mind games from three haughty female STEM dropouts was rather infuriating.
The process eventually succeeded after giving it a little time, space, and grace, but it looks like I'm leaving "enhanced security" disabled if it's so customer-hostile.
If the credentials get stolen from a website database, they’re useless for every other website on earth. No matter how poorly they’re stored, it’s just a public key and is not useful. Hell, they can get code executing on the webserver that collects full login information, and it’s not useful.
Passwords always require full transmission. Hashing for storage requires a proper implementation, which we’ve seen does not happen. 100% of the time. There’s a reason hackers are still stealing passwords from websites after three decades.
Passkeys solve that. Nothing else available to the average user does.
Passkeys are an end run on general purpose hardware largely under your own control, which is a much bigger issue in scale than dealing with customers who can’t access the services they pay for because of some byzantine security or know your customer laws/procedures.
I bought a house earlier this year and the bank froze my deposit I sent to the real estate agent.
I rang the bank straight away and badgered them to unlock it ASAP in case the sale fell through for their BS fraud department to sift it.
They blamed the fact the real estate they’d never transacted with before, I politely told them they’re based in one state while I was purchasing in another.
It took 2 hours of back and forth to get them to send it, even after they did all their security questions.
It’s all a fugazi, they/governments do not want you having large amounts of money - it’s as simple as that.
If they have something like this in place, they will have greater confidence in the transaction being genuine and less likely to block it. In this case, for such a large amount of money, relative to the size of your account, they might still be very cautious about it, but it would be less likely to cause an issue.
My point is the gains are overstated the main weakness is almost always user action. Passkeys will not magically solve all our security problems.
Instead we’re increasingly locked out of devices we buy and told/mandated this is how you’ll use them.
Passkeys aren't solving for security nerds who like portability and have 30 character long passwords, they're solving for grandpa who will happily read their bank's 2FA SMS to the "bank" over the phone. The FIDO alliance has literally billions more of these users than they do users who know what hardware attestation is and how it impacts their auth workflows.
And Grandpa will have fun if he has to juggle 20 passkeys with different security requirements on his devices.
But as I said, there are plenty of UX issues with passkeys, those UX issues however don't include getting your accounts hacked, phished, passwords lost in data breaches, etc, which I'd suggest are a lot worse.
Users constantly fall for website impersonation, this can be solved by your password manager it just has to check the host and the certificate of the login page.
Now browsers don't let password managers do that, I wonder why.
But lets say you don't like the fact that passwords are sent over the wire. I get that I don't like that either. You could just take a random token and have an hmac signature on all your requests, for most cryptographic hashing functions that would probably be quantum secure as well.
But lets just say you don't want to have a shared secret because you know servers get hacked all the time. Totally legit, I like the way you think, asymmetric cryptography it is.
How could we possibly do it? Like ssh with pki on top.
The spec could be literally these 25 words:
Do what ssh does but request a PKI signed certificate instead of a key signature from the server and validate it against your known CAs.
There's functionally no alternative for consumer logins, and certainly not one that doesn't require learning what PKI is. "like SSH with PKI" is a bit "draw the rest of the owl".
Which is exactly what Passkeys does. And it also has built-in functionality to prevent any kind of "Oops! We changed our login method, just ignore the warning and retrieve it manually." social engineering, which a user would often genuinely see when random services move their login page to a different url.
(() => {
// Sites check `window.PublicKeyCredential` to decide whether to offer passkeys.
try { delete window.PublicKeyCredential; } catch (e) {}
// Block passkey requests from sites that skip the check. Password/federated credentials still work.
const creds = navigator.credentials;
if (!creds) return;
const refuse = () => Promise.reject(new DOMException("Passkeys are disabled.", "NotAllowedError"));
const origGet = creds.get.bind(creds);
const origCreate = creds.create.bind(creds);
creds.get = (opts) => (opts && opts.publicKey ? refuse() : origGet(opts));
creds.create = (opts) => (opts && opts.publicKey ? refuse() : origCreate(opts));
})();> I’d like to be clear that there are legitimate uses of remote attestation. By using a website that requires attested passkeys you can be sure you stay safe from accidentally installing a scammer’s fake passkey application that steals your data – the website will reject such a passkey. You might want an attested Passkey even if the website doesn’t require it, since you can use attestation to verify that your software has not been tampered with by a hacker while you weren’t looking.
> As for reasons to not want attestation: you might want to be able to use software that Twitter (formally X) doesn’t specifically approve of, such as Linux. Or a phone with a refurbished operating system.
So the bad timeline is the one in which the industry gradually transitions to "you can't log on unless everything about your system is exactly as we want." Figures.
Before anybody thinks "surely they can't ban all linux users", they don't need to. The systemd folks are also working on a startup that is building verifiable computing into Linux via systemd. So, we have no choice on the matter anyway. It could become of choice of approved distro vs non approved distro.
> So the bad timeline is the one in which the industry gradually transitions to
We have been on that timeline for every other tech transgression. There are no signs that this will be a different timeline.
But there’s definitely a kernel of truth here. 1Password recently began to enforce userVerification: required[1][2], and suddenly on the desktop without TouchID I have to enter my login password to use the passkey on a good number of websites. I didn’t sign up for 1Password 15 years ago so that I have to enter both my very complex master password and very complex login password to sign into websites, the “one password” contract is suddenly broken after 15 years. This experience independently alarmed me about the additional constraints potential of the passkey standard and power wielded by the FIDO Alliance and partnering organizations addressed in TFA, which are, to be clear, useful for security in an organization. (We use userVerification: preferred now btw.)
Therefore, I believe the passkey technology is great for enforcing a standard of security in an organization and stand by my choice for my org. But as a general purpose B2C auth tech, if the additional constraints become widely adopted, user freedom will be seriously harmed.
Edit: I asked Opus 5.5 to vibe code a passkey auth solution in Go a few times without saying anything specific about userVerification. It chose required each time. So expect to see more of these. Oh and vibe coding auth without understanding it entirely is bad, please don’t do that.
[1] https://web.dev/articles/webauthn-user-verification
[2] https://www.1password.community/1password-at-home-31/user-ve...
If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.
* On Windows you can enable Windows Hello for biometric authentication.
* On Mac, as shit as it is, you can buy Apple's magic keyboard with TouchID (for crazy money, but still) and use it while the notebook is shut.
I hope 1Password can eventually consider adding something like face recognition from a webcam as an alternative method.
Unfortunately, without this they are not compliant and it gives a false sense of security to claim it is multi-factor when it's actually only one factor. You'll find the same with other Passkey stores like Kevault that require biometrics as well.
I don't agree with the conclusion, though.
TOTP is great, flexible, and keeps the user in control; however, using a passkey in a flexible password manager (Bitwarden, keepass, 1Password, etc) really does continue to give the user control. And the user experience is dramatically easier than filling in TOTP codes.
To advocate for TOTP over passkeys, we're already relying on an application to generate those numbers (authenticator apps, password managers, etc). I see no reason to not simply continue using those pieces of software to manage passkeys, too.
See my comment here https://news.ycombinator.com/item?id=50049311 about userVerification: required. Passkey in 1Password used to be on par or slightly more difficult than filling in TOTP codes (need to click to approve rather than browser extension autofill and even auto-submit on a large number of websites) but that’s no longer true with a good number of websites requiring userVerification. Now you have to type in your login password on desktops without biometrics. Forum thread: https://www.1password.community/1password-at-home-31/user-ve...
I think the bit about TOTP was mostly a joke, the problem with passkeys is that they're billed as a replacement for passwords but they mix lots of MFA concerns in and make interoperability essentially impossible a lot of the time.
That's simply not true. I'm able to log onto GitHub on my corporate device using a passkey that's kept in 1Password on my iPhone.
Passkeys are built on Webauthn (and ultimately sort of synonymous with it) and that has always been the web standard for all physical key support such as Yubikey and is basically the same as it has been for decades when dealing with Passkeys only with updated UX on top. Hardware support here is pretty good, too.
They’re both equally disposable. You can reset a password just like you can reset a passkey.
Even if your other device is a mainframe computer thousands of miles away, so long as you can photograph the QR code, you can decode it and send the data string for the passkey device needs to it.
The issue that many have with passkeys is that someone will tie a passkey to an ecosystem that they don't personally control like Apple's and then they can't get into their services without an apple device that's onboarded into Apple's ecosystem.
Yeah and neither will anyone else!
My claim is not that passkeys couldn't give you control in principle. It's that the standard readily allows for websites to prevent you from being allowed to exercise that control, and the unclear messaging and UX around passkeys means most users will not even notice should this happen.
Sure, but if you read the article you would know that deal can (and will undoubtedly) be altered. The passkey issuer can demand that the passkey be hardware-backed, and I've already run into passkeys that cannot be stored in bitwarden out in the wild (i.e. they REQUIRE that I use a TPM-backed store in my computer). Eventually it will be a particular TPM-backed store running on an attested platform. Now that's not generally the case today, but make no mistake, that IS the ultimate goal... You will only access valuable services from devices that you fundamentally have no control over (e.g. locked down OS's with attestation before you can access X,Y,Z), so that you can't steal from netflix, skip the sponsor segments on youtube, block ads in your web browser, etc. etc. etc. If you want a preview of how this might all work from the technical side, just look into how TEE works for large-scale GPU deployments right now.
And you can't really blame them. A TOTP 2FA from your password manager is not secure. It WILL be hacked sooner rather than later. And SMS is horrible, expensive, and unreliable.
So far, only FIDO keys provide hardware-backed security ("resident keys", not passkeys) that is nicely segregated into self-contained hardware module. And it does not require you to run a full end-to-end DRM-ed stack.
If you _want_ true privacy and security, that's pretty much the best case you can hope for.
The only difference is that banks will now blame you for any losses caused by hacked devices because it is on paper "unhackable" with a well-updated device, so it is now your fault that their crappy bank app's security was broken.
And you still don't get to use Passkeys with banks, of course.
> Except that those "self-contained hardware modules" are actually rarely "self-contained" but usually an integral part of a smartphone running a huge bunch of mostly-untrusted code and that the containment keeps getting breached, of course.
And it actually doesn't matter if the secure device is designed correctly. Providing a secure channel over untrusted networks is something that we can do easily.
> And you still don't get to use Passkeys with banks, of course.
I can. I'm using US Bank and it supports my Yubikey-bound WebAuthn credential just fine.
Is the audience of this article the kind of people who are already using passkeys and like them? Because, if so, we’re starting at a deficit here. The author is out to get my beloved passkeys that have saved me so much time and pain.
Are passkeys perfect? No. Are they even very good for no-technical users? Absolutely not…they’re incredibly confusing for that kind of person if you ask me.
However, for my workflow, I’ll take them over a password+2FA type of situation where logging in is such an annoyance. The security part of the discussion is very interesting and a lot of the things in this article are stuff that I didn’t know before reading it.
The issue is that, putting on my user hat, I just don’t care. As long as my accounts are reasonably secure I’m much more concerned about ease of use and workflow.
Substitute apple with google, pay card with youtube comment and iphone with android for the "open" experience.
Expand on this? Haven't heard of this failure mode.
tldr from memory: Guy used 2 legitimately purchased gift cards that had been tampered and their codes were used by someone else. His account was locked with no recurse.
I think he could still use his phone, but all the online stuff were locked down. He only managed to get it back after his case reached this website(hn) and senior Apple people stepped in.
I apologize that the headline is provocative. I thought for a long time about how to appeal to both people who are barely aware of what passkeys are but also not put off people who like them. I considered calling them a "Trojan Horse" in the headline as I do in the body (i.e. legitimately lovely, but with a terrible and unobvious problem) but "trojan" has another connotation in computer security.
Nonetheless, I said what I meant. Convenience is how they get you. This convenience didn't have to come with a trap, but thanks to the way it was designed, it does.
The title put me off completely.
I’m tired of people shitting on everything. Especially without offering any advice on how to improve things. It’s exhausting to read. And apparently it’s not even the point of the article. So why is it the title?
Very very strange choice.
The tone hair-splitting makes it seem like you weren't going to be that receptive to the point anyway, no matter how many layers of subtext are inserted to abstract away the actual point, that being - Passkeys are a trap. Do not use them.
It wasn't a pointless rant, you're seemingly primed for something that didn't happen here.
It's a good argument that passkeys are a trap while TOTPs offer the security you need but avoid the absolute control passkeys may hand over, so stick with those.
With passkeys I click once and I'm in like the golden age of using the web with a password manager in 2012. It's a huge quality of life improvement. If people want to avoid passkeys for whatever reason, that's fine but not interested in reading the same slippery slope argument that gets reposted every week.
A recurring issue with these critiques is how they seemingly presuppose passkeys are an all or nothing thing, and losing your passkey means losing access entirely. Which isn't how it works basically anywhere. It's just another auth method, if you can't use a passkey you fall back to whatever recovery method is offered. If passkeys became some user hostile trap overnight I'd just unenroll them and use TOTP, SMS 2FA, email 2FA, or whatever else is supported.
And every critic always attacks this same thing. TOTP isn’t so bad, my password manager can do it. 2FA is fine it’s automatically pulled from my phone.
It’s still phishable. The password is still sent. You haven’t solved anything, you just piled more complexity on top to make it harder. People can still use the same password at 12 websites.
Passkeys never get transmitted. If you hack into a server and steal my credentials, all you get is a public key. You can’t use it at another website. A bad developer can store my password or TOTP secret in a way that makes it useful to a thief. That’s not possible with Passkeys.
No one ever offers an alternative other than saying it’s irrelevant. Despite practical experience showing otherwise.
Passkeys work and make my life better. These constant rants remind me of seeing people argue that the GUIs are a waste of time and no one will ever use them and it’s a fad that will go away and the only reason everyone’s talking about them is companies want to sell graphics cards and mice.
Regarding how I feel about passkeys after reading your article, logically I am reading what you wrote and conceptually understand the trap, it’s just hard to wrap my head around what kind of situation would cause this trap to “catch” me so to speak.
I.e., the upside is real and immediate, the downside is theoretical and tied to future uncertainty.
But as for how it could "catch" you: if you use FOSS devices that are unattestable (as is the case for the LineageOS phone and Linux laptop I exclusively use), you may one day find you can't use many websites.
Passkeys in theory are great, but the capabilities of the spec are worrying. Defaults can and do change, and when they do, so follows 99% of the population, and then you find yourself either getting blocked out of services because your hardware/software doesn't comply, or you give in.
But on the other end, it might not matter anyways. Apple, Google, Cloudflare, are already pushing similar garbage and now you increasingly have to scan a QR code that verifies your mobile hardware to use a desktop.
I'm sorry, what? Who has more than one password manager (other than a personal/work split)? That's absurd and not something anyone I've heard of would put up with
Although this isn't true because actually with a password you have to choose how to generate it and everyone chooses different ways.
This (before they go on to describe actual passkeys) sounds like object capabilities to me. Capabilities combine designation and authorization so if you don't have it, you can't use it. It's the type of security that we should be moving to.
Passkey attestation sounds like a nightmare for user privacy and for anyone that doesn't use a major corporate operating system.
That ... doesn't seem like a concern unique to passkeys, though?
It seems more like a policy rather than a technical aspect.
e.g. A website might decide they will only provide services if you upload a photo of government ID, or pass a verification where you show your face.
If it's software running on someone else's computer, you don't get full control regardless.
I don't have the choice to use a bank card online without 2FA - it's mandated. I can either use one of the options provided or I will go to my bank in person and close my account. Those are the possibilities. Nothing else.
Passkeys are only one kind of 2FA.
Yes, banks are particularly bad at this because their threat model is strong.
My bank required installing an authenticator, but apparently recently they've allowed SMS based 2FA. It seems users complained/resisted and they had to accommodate them. Maybe you should give feedback to your bank. Be the uncompromising minority.
I think 2FA is fine and a good idea, but I agree with the author that passkeys seem fraught as designed.
Passkeys offer the same and more security but are less of a pain for the user.
Convenience is precisely the thing that big tech established tech platforms want to reward their users with to keep them around. The undeniable convenience of passkeys didn't have to come with a standard that is threatening against unattestable devices like my Linux phone. But it does, and that means passkeys are a way that the industry can discourage people away from using non-Google/Apple/Microsoft-approved devices.
(Apple didn't join the FIDO Alliance on Passkeys until they made sure attestation was an optional feature and no longer a requirement, for consumer privacy reasons.)
me: Can you show me my stuff?
website: HTTP 401, who are you? I understand EasyAuth 1.0, if that is good for you.
me: Sure, here's my EasyAuth 1.0: Hi <website>, I'm <user_id>. The time is <timestamp>. Signed, <digital_signature>.
So no one implements it for site-local login. Even the biggest sites like Amazon, for example, still use old-school passwords+2FA.
The way secure auth works for small sites is that a third party[1] authenticates you, who the website trusts more than mere users. And that's where all the complexity comes up. You need something secure stored on your known-secure device, a password alone won't do.
[1] In practice Google or Meta. Occasionally Apple or Microsoft. Everyone else is noise.
I guess I am envisioning the user agent doing all of this. You go to a site and create click account, your browser shows a pop-up: "<website> is asking you create an EasyAuth account. Would you like to create an account on this site?" If you click yes, then the user agent does this in the background:
website: Sure you can have an account. Use this token <token> once and this ID <user_id> forever.
me: Ok, here's your token <token> for ID <user_id> and my public key is <public_key>. Signed, <digital_signature> to prove it works on my end.
Maybe generating a unique public key for each website is not substantially better than generating a password, but at least a signature cannot get stolen on the server side or in transit. You wouldn't have to change your public key if their database got slurped.
Passwords also aren't standardized, so they are pain to generate (special characters required or disallowed?). They don't reliably autofill into a website. You still have to go through a manual flow to login; user-agent doesn't just keep you logged in. I guess I would be fine if the user-agent knew how to authenticate me to every website.
Maybe this is what the passkey system was before it got designed-by-committee'd into oblivion. I am just always amazed by how complex authentication is when the user-agent should be able to handle this rather painlessly.
That's literally what a passkey is, that the linked article argues against. It relies on the platform vendor of your device hardware to validate the full stack of software. You can't just do it in a browser because anything that reads the browsers data (or attaches a debugger, or runs the browser in an instrumented VM, etc...) can exfiltrate the key.
While that is an option, I've been using passkeys on Amazon since 2023.
If you write a long article about the merit of passkeys and there is no occurrence of the string "phish" in your article, I am afraid I cannot take your rant seriously.
Again, this stuff is not merely theoretical. YubiKeys have been a thing at Google and other major tech companies for almost two decades now and the effects are well-studied.
[1]: I have found for some weird reason, this is often overlooked and misunderstood in the industry. People even know about SIM swaps and stuff like that, but don't realize OTP is not phishing-proof.
Yubikeys are a great second factor honestly. But do you want to use a Yubikey as a passkey? Sorry you are likely dissatisfied. Many websites and apps (especially apps) support passkeys but would prohibit using your Yubikey as a passkey.
Bullshit. Literally number one attack vector.
> Password managers are also checking the domain before supplying a saved password.
Password managers are not anywhere as ubiquitously used as you'd think. Even if you rely on password managers, you encounter scenarios where the website relies on a different domain that's not paired appropriately. Some "legitimate" mofos like Plaid used to ask password for third party website. Consumers don't see a password manager failure to fill out a password as a security issue. They see it as a routine password manager failure.
That’s an out-of-date view. The number one attack vector these days is cookie stealing. The prevalence of 2FA even weak ones like SMS-based 2FA has made plain old phishing so much less effective.
YubiKeys have been a thing at Google and other major tech companies for almost two decades now and the effects are well-studied.
No, fuck that. Just let me use an SSH cert at that point. The existence of phishing is a comparatively minor evil.
Sharing and phishing are on two different axes. You can have shareable credentials that are phishing-resistant when used.
You can have hardware-backed SSH keys that are not cloneable. You would need the browser to prevent phishing while still using SSH agent as its underlying signature mechanism (implied by my "in a consumer package").
and the websites are usually justified in saying that.
lol. lmao even
None of us had a say in our existence itself. Skin color. If we cannot have a say over our provenance itself "ultimate control" is just an empty phrase.
Their concerns about big corp might hold some meager merit but "beware the avarice of rich people who view you as a sheep in their flock whether you want it or not" isn't really new.
The point is very simple - there was once a day when we had considerably more control over the way we use computers and the networks that connect them. That is slowly being taken away, piece by piece, until the only path to use them is to 'consent' to whatever demands the corporations put up. Not that this doesn't exist already, but today will seem like the wild west in comparison to what's coming.
"Big tech is coercive and evil" isn't a new view, but "passkeys are one of their tools and not just some agnostic technology-first nerd solution" is still not widely known.
And our agreement doesn't stop there. No views I encounter anymore at my near ripe old age of 50 are new anymore
Social conservatism whittles value statements down to a finite subset of cause-effect. And I don't mean just flag waving holy book social conservatism. This community is clinging hard to social tropes the other 8 billion are moving on from
Run a trend analysis on the comments of HN going back decades whole lot of repetitive gab about state management in a machine; chef or bash or llms... same old ground truth; don't speak too far outside the experience of readers or the inherent short term prediction engine in their brain will segfault from a biological memory overflow
Religious people are not the only ones who live in rhetorical fantasy
End of day the provenance of any socialized idea is some rando I have no obligation to march in lockstep with; physically or philosophically
- Never underestimate the effectiveness of school yard persuasion.
This is less secure than pure username+password in principle because it gives an impression of greater security while actually delivering the important secret in plaintext. This can cause platforms to enable the higher trust features, or have additional confidence that someone is not an attacker, even when either one would be highly inappropriate.
TOTP does not have this problem since the secret is enrolled once by the account owner and then never communicated again, especially never helpfully to an attacker right when they need it.
> One use case is particularly intriguing to me. In principle, remote attestation can also be run in reverse, to verify that the server you connect to is not doing anything you don’t want it to be doing (such as stealing your credit card number, or keeping backups of the posts you delete). Sadly, to my knowledge, no major platform has ever implemented “reverse” remote attestation this way.
This is only possible if you've audited the code in order to approve it. In practice, this requires auditing the entire SBOM, manually, yourself, for every single platform release. Or deferring to someone else to do it. I expect this will never happen.
Epic for example has at least 3 different ways to load the pass key e.g. username first, passkey first, username + password, then passkey. Luckily their app lets you in with Passkeys alone
Walmart prompts for username first, then passkey, then it sends you a verification code to your email address.
The issue is that every site has a random flow of username, password, oauth (then a few oauth screens), passkey, 2fa and so on.
Authentication has become absurd. None of this is making people safer. If sites are seeing less fraud reports, it's likely they are harder to detect rather than less frequent.
Use proper password managers, like keepassxc. Then you have control. But problem is that not all sites support that. If you can't use the above - then yes, passkeys are bad, especially if they become mandatory.
> What’s important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys
Passkeys are _by_ _design_ representable as clear-text strings. You can export them and sync between devices. I'm using BitWarden with a self-hosted Vaultwarden for the server-side to do that, for example.
That's not the intention of the relevant standards.[1]
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
Sigh. IT LITERALLY IS.
The name "passkeys" itself means "exportable keys":
https://fidoalliance.org/passkeys/
> When a user creates a passkey on any of their devices, it gets synced to all the user’s other devices using the same passkey provider that is also signed into the same user’s account. Thus, passkeys created on one device become available on all devices. > Notably, if the user gets a new device and sets it up with their passkey provider, the user’s passkeys are synced and available for sign-in on the new device.
The resident keys (the ones created by platform-specific TPMs) are not passkeys. And they had been standardized _before_ the passkeys.
> The name "passkeys" itself means "exportable keys":
> https://fidoalliance.org/passkeys/
This does not follow from my understanding of the word, and the words 'export' and 'exportable' don't appear on the page you've linked. Nor did I see anything indicating that was a core part of their design from a cursory reading of the page, although I might have missed something. Your quote certainly doesn't imply 'exportable'.
Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended. To quote Tim Cappalli, who's credited on the W3C spec as an editor[1] and maintains passkeys.dev,[2] so presumably knows what he's talking about: "Passkeys should never be allowed to be exported in clear text."[3]
[1] https://www.w3.org/TR/webauthn/
[2] https://passkeys.dev/about/
[3] https://github.com/keepassxreboot/keepassxc/issues/10407
I literally provided a citation.
> Syncable? Yes. Exportable? Yes. Clear text? Sure, behind the scenes. Exportable as clear text? Yes, but not intended.
A syncable credential is by necessity representable in clear text at some point. In comparison, resident WebAuthn private keys NEVER leave the secure device.
> [1] https://www.w3.org/TR/webauthn/
WebAuthn is a _superset_ of Passkeys. Here's the citation from your own linked page:
> This use case illustrates how a consumer-centric Relying Party can leverage the authenticator built-in to a user’s devices to provide phishing-resistant sign in using multi-device credentials (commonly referred to as synced passkeys). ... > A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.
That I said does not support your statement.
> A syncable credential is by necessity representable in clear text at some point.
I never said this was wrong.
> WebAuthn is a _superset_ of Passkeys
I don't see how your quote illustrates this, and I've only heard them referred to as the same thing. Would you care to elaborate? And maybe provide an example?