Passkeys are not a trap(scotthelme.co.uk) |
Passkeys are not a trap(scotthelme.co.uk) |
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.
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.
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.
I don't use passkeys anywhere for fear of losing access. I just don't care enough to study how it really works. With passwords, I occasionally print out all my important passwords and store them in a safe and I know there's no way I could lose access.
Me: The person who posted this post critical of The King on Facebook was totally not me!
Police: Here's "a WebAuthn attestation" that told Facebook "the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up" and it fits Evidence A.
No thanks.
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.
Currently they aren't tied to that root of trust.
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.
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.
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
Source: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
Passkeys have benefits - but they also have problems. Many people just don't think the benefits are worth the problems. And many people are afraid that sites will just stop accepting passwords in favor of passkeys, leaving people worse off.
And the solution was: make it the user's problem.
Yay.
> 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.
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.
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.
But what is the solution here does anyone know how to make this good?
you can have a TOTP variant which has the browser display a challenge string & QR code, authenticator generates a 5-6 digit response. include more entropy in the response if you want to do away with the password entirely.
passkeys are trash, I would never opt for dedicated hardware (or a cloud service) and using them with a password manager is extremely messy when you want the password manager to be properly isolated from the rest of your system.
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.
I mean you're logging in to some software, surely they need some info from you?
Contributions and feedback are welcome! GitHub link is at the bottom of the page.
True, but doesn’t actually refute the original.
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.
> 1Password for iOS exports ... directly to other supported apps, including your passkeys.
They pick the list of other supported apps. There is no ability to export to a standard encrypted file, nor is there a way to develop an open source app that can receive an export over the objections of 1Password Inc.
Passkeys are a trap, trying to lock users in to the service providers.
I did say I like and use 1Password, but I do remember that they switched from a one-time payment model to a subscription model, and have now stopped supporting the old software and only support their subscription software. If it wasn't for my non-tech-savvy, aging family I support their usage of 1Password for, I would still be on Keepass[XC] for my own private usage.
Since passkeys are tied to verified devices, they guarantee absolute de-anonymization -- and further spread that advertising "wealth" by seamlessly linking across devices, and therefore to their respective corporate stakeholders (i.e. via bluetooth to conveniently login on a laptop via a phone-domiciled passkey).
Username + password at least requires circumstantial marketing analysis to "verify" whether a user is who marketers think they are. But with passkeys, your login confirms your Windows account ID, cell phone MAC address, home address, what have you.
I think they've been implemented well in some cases. I think they've been implemented poorly in others.
So it goes.
>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?
Then when most of the population is using passkeys everywhere in a closed ecosystem, now what is the response if friction slowly starts getting added. OK, you can still use what you like, but only export to other approved players. OK, you can still use unattested, but it's off by default now, "advanced users" can go enable it with this checkbox in the settings. OK, manual is still an option, but now it's buried deep and behind dark patterns and requires a text command. Hi everyone, we have statistics to show that only 0.85% of our users still use unattested keys. The support burden and security risk is now too high."
Like, we've seen this movie before.
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.
The phishing potential?
Just came back from doing a bit of research and apparently I can use Bitwarden to generate and store passkeys.
I have been dismissing the entire concept because I assumed it had to do with hardware keys, which I would never trust. But if it's bitwarden, then I can easily do a backup, and that would be very reliable.
I think I'm going to start using passkeys... :D
You can’t just stop using those websites if your university uses them for student/employee accounts.
Initially, they will probably “just” require hardware serial numbers or similar (so they can join IDs on the backend).
There are already serious proposals to require live web cam feeds for porn site login biometrics purposes, so I can’t really come up with any hyperbole to add.
Until we change our laws in the US on this front, I will continue to use passwords and hardware keys separate from my phone box.
no thanks, passwords are not a burden to me
> 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?
Any of them? All of them?
"Starting next year, only Google Authenticator and Google Chome passkeys will be valid for gmail logins. Help us keep your account safe by limiting access so ONLY YOU can read your emails"
"Good news! Your Instagram account is getting safer from hackers and spammers. As of next month, you'll use your Meta Metaverse token for all logins to Instagram, Facebook, Theads and WhatsApp"
Google already forced OAuth2 on Thunderbird [0] and the rest of the email-client universe.
[0] https://support.mozilla.org/en-US/kb/automatic-conversion-go...
The whole point of OAuth2 is to allow logging in to some untrusted 3rd party site via an authentication provider without having to key your password into the 3rd party site.
a) Local client software like Thunderbird is/must be trusted, it's not a random 3rd party website.
b) App passwords remove the risk of Thunderbird stealing your password, even if for some reason you didn't like typing a password into Thunderbird.
c) Google is both the Authentication Provider and the Resource Server in this example, so it adds zero security.
Also, is there a reason Thunderbird or other clients couldn't use OAuth? I'm fairly certain I can login to GMail on Mail.app in macOS and other clients, so they're not using that to lock people into the official app or their browser
I assume Mail.app had to do the same.
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.
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.
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...
I still prefer a good password written down in a paper book, with multiple methods of 2FA. But I know there are attack vectors for that.
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.
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.
QED, a trap.
The standard and implementations are also unnecessarily complex and obtuse. IMHO passkeys are not a good technology.
Few weeks later
>let me tell you why you should NOT use XYZ!!
Classic HN.
That being said, password and 2FA is the best combo, where you control the token of the 2FA and it’s on a separate app/platform/etc than where you have your passwords.
On topic, I’m not sure I even trust my own password sanitation, and seeing service A and B hacked every other month, I feel weary. Knowing that someday my passwords might be compromised as well, so what should I do as just a person who can’t remember things? Write them down, I guess.
Do passkeys have issues? Sure. Most of them are UX and are being worked on. As a user, I 1000% immediately register a passkey when a site or app offers it as at least on iOS and macOS, it is a superior user experience IMO and more secure. I never worry if I'm getting prompted for a Passkey, am I on the right site?
Also the remote connect functionality of modern browsers and mobile operating systems makes it trival if I need or want to sign into a personal account on my work PC where my personal passwords are not sync'd. Need to get into my personal GMail in an incognito window at work? No problem at all.
Anti-Passkey folks are just people who want to be against something to be against it
Which in turn makes it harder to track vs. your /64 which is approximates your old NAT'd public IPv4.
> Thankfully someone with some sense
Cannot be asserted with this:
> I saw that post title and didn't even bother to read it.
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.
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 want to have a Password Manager which I need to unlock when I use it. I also want to keep my 2fa and not break it due to passkey usage.
GitHub was also super shitty with it, suddenly a passkey broke my YubiKey login...
If it was easy to migrate between services, then i would be a lot more open to using passkeys.
Also, many if not all of the sites I've got passkeys setup with support multiple keys, which I sometimes take advantage of. For example I've got a passkey into my Google account in my Apple account ecosystem but I also have a physical Yubikey setup as a Passkey device, in case I were to get locked out of my Apple account
On my MacBook with the latest macOS I still can't use them.
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.
Do you have bluetooth disabled half of the time?
Plus, none of the sites that I use passkeys for would I be locked out. They all have account recovery procedures just like if I forgot my password. And, finally, for the important ones like my Google account (where my email lives) I have other non-Apple devices like a Yubikey setup as additional Passkey/FIDO authenticators
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.
An app password is basically just an API token, it's up to the backend what powers it grants.
OAuth wasn't about lock-in (since any client can support it), it was about getting off shitty legacy auth
You shouldn't need a web browser to read email.
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?
Thanks!
I believe a reboot sometimes restores functionality.
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.
How do you log in without having the passkey?
>I've never actually done it
You can't be serious.
If it's easy, go do it, find out, and come back here to tell us about it.
When a website prompts me to set up a passkey, depending on the device I happen to be using at the time it could end up going to Google password manager, Samsung password manager, iCloud Keychain, or Windows somethingorother.
What happens when I go to the same site on a different platform? 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? What if I want to consolidate them all in one platform just for the sake of being organised? What if I lose or simply don't have the device with a certain passkey near me?
I don't have the time or patience to work out any of that, which might absolutely be a 'me' problem, but TOTPs are pretty sodding frictionless in comparison. Scan QR in my chosen manager; type number into website; done. Why are passkeys better?
Most password managers don't even allow you to export/backup the passkeys yourself. (Bitwarden is an exception.)
Instead, password managers support a finicky app-to-app transfer protocol called "Credential Exchange Protocol" (CXP), where you install two password managers at once, and they convey your passwords + passkeys, without ever generating a file that you can read. (And Microsoft's password manager doesn't even support CXP yet. As of today, you can only do it on Android and iOS.)
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.
If you use the same cloud-sync password manager everywhere, passkeys just work. If you don't, you'll have to use Credential Exchange Protocol to transfer them, which is a hassle.
It’s up to you to decide whether protecting yourself from being tricked into exporting your passkeys is worth sacrificing your ability to read them.
The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"
So far, it's about 30% of sites screwing it up...
I can’t adopt Passkeys if I’m not certain they’re going to work as well as my password manager and Authenticator app, which is to say 100% of the time.
When sites ask to set up passkeys, it’s usually native passkeys (especially on iOS). And figuring out how to get the flow to set up a LastPass key by default seems unusually difficult.
I also use a MacBook, windows desktop, an iPhone and iPad. I use Firefox, edge, brave across these devices.
When I say “passkeys are a trap” they are a usability trap where no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys.
That's the issue I had with Okta a few years back. I used a password then later added a passkey through Bitwarden on my work laptop. Bitwarden hadn't yet implemented passkeys for mobile.
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.
My suspicion: There is a significant chance I will lose access to one or more account by doing this, so I'm not going to until the air clears. I don't trust the motivations of the services pushing it.
This means you never send your private key to the site, so if their database is compromised they only get a public key, which can’t do anything (it is public, after all)
No amount of phishing can get you or your client to hand over your private key, because there is no use case where that is required. There is no possibility of MITM, since your private key is never sent anywhere in any situation.
As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
I've never fallen for a phishing attack and any attack targeted and sophisticated enough to catch me is probably going to be sophisticated enough to steal/hijack a passkey anyway. In the extremely improbable event that I did get phished and somebody got into my account somewhere, they'd only have access to that one account because unlike most people I don't re-use passwords and recovery would no more complicated than contacting customer service and resetting my password with them.
Considering the horror stories of people who been screwed by using passkeys, I'm sticking with "not worth the trouble"
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).
What do passkeys offer users that rand strong password + password managers don't?
They have to be transmitted. They (or their hash) have to be stored. And so so many get that wrong.
There is nothing to prevent you from entering your super secure unique password on the wrong site if you get phished.
Passkeys don’t get transmitted. They’re used for cryptographic signing.
Passkeys can’t be entered on the wrong site, the sites they work on is an inherent property of the key.
You can’t store a passkey wrong on the server, it’s a unique public key. If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
Unique strong passwords, TOTP, 2FA, one time sign in emails, none of those offer this stuff.
Passwords are fundamentally broken. They cannot be fixed. Cryptography is the solution in passkeys are the implementation.
But in my opinion, the solutions that passkeys provide come with the costs that are being discussed here, and I haven't found the trade-off worthwhile.
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.
One blessing with passkeys is since I set it up for my mother with her Amazon account she has not once had to ask me to help me reset her password. At least once every 6 months I would have to help her sort things our as she would forget it, reset it and then forget what she reset it to and can't reset it again as she hadn't clicked to update the password in her password manager so it had an old or incorrect password, etc. Always a pain to sort out. Not happened once since switching her to a passkey which is wonderful for me.
Also it is essentially impossible for her to use the passkey on a fake site. Multiple times she has fallen for phishing emails with realistic looking site logins and she would just blindly enter her username and password as many elderly people do.
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?
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.
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.
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 ...
Why, specifically?
(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)
New and interesting ways to get locked out of your system.
Then the user still controls the passkey using a password and then everything else flows from that.
You click the "log in with QR code" button, scan the QR code, and authenticate using your phone.
Unfortunately that only works from phone (and watch) to computer. If you don't have the passkey available, you click "forgot password" and set a new one, same as with a password.
Passkeys provide perfect protection from phishing attacks, since it's impossible to send a passkey to the wrong domain. That's a huge improvement over TOTP.
Re: it being confusing where they're stored, I agree. The solution is to make sure you store your passkeys in your cross-platform password manager. The experience can be confusing though. In Chrome I've found that by default when creating a new Passkey Chrome offers to store it first. But if I click cancel, I'm then given the option to store it in 1Password where I want it.
This is the same problem we've had for 20 years with password managers, though.
The solutions are mostly the same as well (with the change to a QR + BLE based mechanism over manual transcription to go cross-device, and a protocol to support moving passwords and passkeys over to different software rather than using a plaintext password CSV export).
Many password managers also manage passkeys (and were managing TOTP before).
Heck, as an engineer even I don't get them. What ever happened to password + yubikey?
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).
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.
>What if I lose or simply don't have the device with a certain passkey near me?
Then you will need to use a fallback authentication mechanism or will need to wait until you can get the device. TOTPs have the same issue.
I've done authentication projects for financial institutions that were actively targeted by phishing attacks, and it is difficult to mitigate TOTP phishing. Defeating TOTP is very much in the standard playbook for high-dollar scam operations.
Moreover, the large majority of ordinary people are going to use whatever comes with their phone anyway, which can then lock the key in the device's secure processor by default independent of remote attestation. So then it's not getting you anything for those people and the primary thing it does is to impede Linux Girl from using Linux and anyone new from ever trying to create a competing mobile platform or even a usable non-Google fork of Android.
The obvious way to satisfy people is to remove support for remote attestation from the spec.
If it gets lost for whatever reason, I don't care, I will login again with regular username/password.
So as long as you also have a regular username/password login, phone passkeys are great time savers.
"What happens when I go to the same site on a different platform?" = "If you meant device, then Chrome has a feature to allow you to use a different device such as a NFC YubiKey"
"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?" = "Good, Passkeys are doing their job correctly and you cannot export credentials"
"What if I want to consolidate them all in one platform just for the sake of being organised?" = "Then log in and add more passkeys to things rather than copy-pasting passwords everywhere"
"What if I lose or simply don't have the device with a certain passkey near me?" = "You should have multiple passkey's or use the various cloud versions that exist"
I'm perfectly happy to take responsibility — when using a well-designed system that isn't a massive pain-in-the-arse up front designed for vendor lock-in and to penalize small vendors.
Criticizing the new system isn't avoidance of responsibility, it is demanding a product that is worth using, i.e., NOT designed for the manufacturers to extract more money from us without providing more value or locking in their market position, but designed to be actually useful to the people who will actually use it.
EDIT: add last 8 words
It is plainly obvious that the worry isn't attestation per se, it's the restrictions that attestation may in the future require when they turn the dial on restrictiveness up, that was extremely clear to me from reading the first article. 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. Most of this article makes sense, but this particular line makes me wonder how the author got it so far off the mark.
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.
It's true that passkeys do not require hardware and OS attestation today, so all of the specific examples you cite are true. But the point remains that that passkeys can be EASILY extended to require hardware and OS attestation, and this will happen.
Banks have already done this. Before using an app was optional. Play protect was optional. It's like my uncle ted used to say, techonolgy is not optional.
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.
Am I missing something? "Attestation tells websites what the authenticator is but it doesn't tell the website what the authenticator is".
The entire argument in this blogpost amounts to "nobody would ever turn on passkey attestation because it would require migration of people who already setup passkeys" which is a questionable argument- you could trivially imagine allowing unattested passkeys for existing users, but require it for new users. Most websites don't yet support passkeys to begin with, so this argument doesn't hold for the majority of websites.
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.
Not so easy.
I've worked at places where we use a password manager to manage lots of passwords for random services that we subscribe to. The engineering manager always says "you can put your own passwords in for free" and I say "no thanks, they're going to get hacked" and then six months later... they get hacked.
I use the password manager on my iPhone because it seems pretty secure and it is so miserable to type passwords in on a phone but my other solution for passwords has used cryptographic generation with the database playing only a secondary role and it is fine for passwords but does nothing for passkeys.
> 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.
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.
Dear Yubico / Kensington / Google Titan, can I export my private key components to this other device, or even print them out on paper for storage?
No - you're just an untrustworthy user granted the fleeting privilege of using BigCorp devices. Now stop asking such questions or you might have your attestation revoked.
Largely false. The Pixel verifies the OS and will reveal `verifiedBootState != Verified` on GrapheneOS in the attested passkey at registration, which websites may choose to reject. Apple Silicon has an undocumented SEP which prevents Asahi Linux from accessing it. There may be other examples now or in the future.
Also, I think you can deduce the device color from [1] on Android.
So, in conclusion: https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b...
[1] https://source.android.com/docs/security/features/keystore/a...
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
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.
> I have a sneaky suspicion that some of our failures with various RP's is because they are only accepting certain authenticator GUIDs.
This comment from the KeepassXC maintainer makes me feel like the whole spec is already completely flawed if such a situation is even possible.
I know where my password manager syncs, it's on all my devices. Passkey prompts always seem confusing, I don't know if it's going to save to my browser, or my OS, or if those are gonna sync on what devices. It's just more confusing.
What would I gain from using a passkey?
The number one gain I see with passkeys is that they are phishing resistant. The biggest issue I've had with TOTP keys is they aren't phishing resistant.
Forcing people to use passkeys gives the authentication layer a stronger means to ensure that people are logging into the correct domain. A password manager accomplishes this, but it's very difficult to enforce. (I've heard a number of variants of "John Smith sent me an important document and when I went to open it, the password manager didn't work so I just copied password")
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...
They are.
This cannot happen with passkeys at all because crypto magic.
I think they are a trap. A usability nightmare. So, I acquiesce to a passkey to a site while on my iPhone and now I cannot log onto it from my work desktop in Firefox. An older person sets it up on his or her Google account, gets a new phone (iPhone to Android) or Android to iPhone doesn't matter and loses access. We know that Google won't help a regular consumer with anything.
Syncing may be a thing in theory but the friction is huge.
---
The author has strong incentives for the success of passkeys.
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.
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.
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)
That's where the trap is.
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.
> 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.
One of the most frustrating issues with Apple's UX.
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.
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.
Maybe it was too strong to say the were a "trap", but it is also too strong to say there is no worries here.
> This one can be tricky because I've seen many sites using passkeys to replace passwords, but that's not something we've done on Report URI, passkeys are used as a 2FA mechanism.
[0]: https://scotthelme.co.uk/xss-is-deadly-for-passkeys-the-hidd...
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.
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...
Practical experience from Austria where attestation is used to limit which hardware tokens can be used for the EU digital identity: it sucks. You're limited to a very limited number of keys: https://www.id-austria.gv.at/de/hilfe/hilfe-zu-ida/authentif...
Now: will more people do this? I don't know. But I fault the standard for enabling it in the first place.
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.
That leaves 2) dedicated hardware and 3) dedicated hardware. Great. (see the “my house burned down” article/thought experiment as to why I’m against that.)
They can request you store the passkey in something non-exportable, but many software passkey providers simply lie about being super duper secure.
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.
I'm generally pro-passkeys, but also acknowledge they are a hot mess for the average non-techy consumer. And there does seem to be room for the screws to tighten, and we definitely need to resist that.
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.
Like SecureBoot.
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).
At the same time the current authentication horseshit of the internet in 2026 is awful. I routinely spend 3+ minutes trying to log into a site - first it blocks logins because of my VPN, then it requires a password reset, then it requires me to login with new password, but then it needs email verification, but then I don't get the email so I have to click resend, then I type in the verification and then it asks for blah blah blah.
I am grateful that LLMs are going to be doing 95% of my browser usage very soon.
It is genuinely an ordeal.
Now they run "Officers are watching! Click it or ticket!" as an advertising campaign.
And I'm not arguing that seatbelt laws are bad per se, just that any time there is a pathway for more control, it will eventually be taken, even if assurances are made that it will not happen.
Most consumer websites won't use attestation.
Places where additional security is required (bank, employer, etc) can.
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
Passwords are client-neutral. Passkeys aren't: you can force a certain client, and now those clients can force an OS through attestation.
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.
most will come with free personal accounts for employees, if they want and choose to set them up. those are separate, and have smooth offboarding for the no-longer-employee.
"free" because im not sure if your employer pays for it or if its like a free benefit to a bussiness licence
If I had to trade off the risk of a password manager being hacked versus password re-use, I'm going to strongly recommend to people generally to use a password manager. Yeah there's a lots of "if this, if that"--but that's almost a universally better risk for most people.
- User account with access to the SaaS password manager was compromised.
- User account with access to the SaaS password manager was compromised.
- User account with access to the SaaS password manager was compromised.
- Password safe file (keepass) was compromised/leaked and its (medium-strength) master password was presumably brute-forced.
EDIT forgot one:
- Password manager was used by a user-facing web backend, which unlocked it with an unscoped read-everything master password. Web backend was hacked, predictable consequences ensued.
My password manager matches off of domains too, so it wouldn't suggest to autofill on a phishing site.
anything can happen. if your passkey stops working because you're using it from your smart fridge to access your banking app, then just use your password anyway.
Ideally you should be isolating your passwords across the company so that one user doesn’t compromise every login, no?
If we don't add decent sharing to passkeys then people will continue to use passwords, which is worse for security than adding a sharing feature for passkeys.
If you do not have access to your personal Apple account on your work laptop, you would need to find some other passkey provider with native integration.
Under Settings > Privacy and Security, look to see that Firefox is listed and has access under "Passkeys access for Web Browsers". Unlike a native app which only needs passkeys for its own services, Firefox needs access for every potential service you might hit over the internet.
Then under General -> Autofill and Passwords, you'll see any apps which are registered as system password managers. Unfortunately this is a subset of the ones which register on iOS and I'm not familiar who has done integration yet in their Mac release - Chrome (with GPM) for instance is not listed even though it is available on iOS.
I will poke at this a bit:
> As for getting locked out of your account, losing your passkey would be the same as losing a password. You would need to follow the site’s password reset flow, and if you can recover from a lost password, you can recover from a lost passkey.
Do you think this is one of those scenarios that sounds reasonable at first, but can get torn apart by unknowns, edge cases etc? To use an analogy from a recent HN thread that is stretched a bit, is this like saying "If you use a crypto hardware wallet, you're safe", then reading about compromised hardware wallets due to something outside the assumption set.
I agree - and that makes me wish that the messaging was more clear from passkey supporters. Some may be genuinely confused and talking about one or the other mode (or not even realize that multiple modes exist), and some may be trying to claim the benefits of one mode while/or handwaving away the tradeoffs of the other mode.
On top of that, secure boot doesn't require remote attestation. If your device doesn't like the new configuration then it doesn't release the key. The site has nothing to do with that except insofar as you need the key to sign into it. Your device manufacturer's key doesn't have to sign anything, all your device has to do is not give up your key unless the device is in the configuration you specified. And if it will do that then it would also sign an attestation to the same effect, so remote attestation still provides you with no advantage whatsoever.
Meta's implementation by contrast is bad, in my opinion. You are only allowed one passkey (so one login ecosystem/hardware key allowed) and it completely bypasses 2fa and security tokens. So, someone looking for more security must avoid passkeys "altogeher" and use password + U2f security key and the passkey only being allowed in a single ecosystem means that password/phishing lanes must remain open. All you're doing is disabling 2fa on a key that is likely sync'd to all of your devices. All that said...it may still be a security improvement for most users in the real world in practice, I just find it a very annoying and confusing set of security decisions.
Seems that way. Better luck next year, passkey standards(?) people. Hope it’ll be ironed out at some point.
Other password managers do, too: https://bitwarden.com/help/auto-fill-ios/#keyboard-autofill
I think passkeys make a messy credential situation even messier, but make a tidy credential situation even tidier.
Isn't that a single vendor (or two)? How is this not lock-in?
> 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.
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.
In my experience, migrating between Apple Passwords and Bitwarden worked without issues, in both directions.
The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.
So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.
The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.
Microsoft Authenticator, Bitwarden, 1Password, etc. all support storing passkeys and support multiple hardware platforms.
It's no different than making your own decision on which password manager you want to use.
There are an open standard. You just have terrible software.
Saying it's an open standard, and that it's just all the major players I'm forced to interact with that make it suck isn't very helpful. That's like the people that say "Don't like iOS? Build your own successful mobile OS lol"
I’m sorry you have multiple pieces of software that want to be in charge, but aren’t passwords the same? Because Chrome and Firefox both want me to use them for my passwords. It’s not a problem unique to Passkeys.
It’s just everyone ignoring user preferences to try to score stickiness.
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.
> 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.
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.
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.
It seems like one of those things that only works if you're sticking to one ecosystem.
Only in theory. Suppose you are a bank, which enclaves/sources/devices do you support vs. not support? What do you do for users on a desktop PC that don't have an enclave? Phishing sites will likely leverage your weakest enrollment option.
got a good chuckle out of me. your optimism is inspiring.
Can you walk me through how that would work?
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?
In theory, if everyone did everything correctly and followed best practices, passwords would work quite well.
Reality shows we are not anywhere near there.
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.
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)
It is a pretty big red-flag.
But that is not a flaw in passkeys. And there have been bugs in password managers that expose standard passwords as well.
Typically the user gives a website their public passkey, which does not need to be kept secret since it’s public. If the website is hacked the attackers only get information that is already public.
You seem to be talking about a scenario where a user’s private keychain on their computer is compromised and the attacker is able to access other systems from that same machine without the user’s knowledge. (Note that the keychain data is itself encrypted so can’t be used from a different computer.)
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.
What do you image happens with passkeys?
> They (or their hash) have to be stored.
What do you image happens with passkeys?
> If your entire database is stolen, it’s useless. No one else can login with your credentials because they don’t have the private key.
From the consumer, do you imagine a hacker has my key to unlock my password database?
From a service provider, do you imagine they are not using encryption at rest?
> Cryptography is the solution in passkeys are the implementation.
Do you imagine cryptography is not used with passwords?
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.
- you can't get phished
- you dont need to worry if your password is securely stored
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.
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.
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.
If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.
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.
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.
A phpBB forum era classic!
Don't assume everyone coding a login page is as competent as you though...sadly.
I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.
Several of the successful attacks that compromised passkeys have been because of flaws in the OS, or the browser, or the password manager, but none of those things are going away any time soon. Passkeys depend on those things, which means they aren't are solution to the problem of phishing. They just make phishing harder.
Passkeys also make things harder for the legitimate user though, and there's a very real question of whether the protection they offer is worth the trouble.
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.
right. and in an office setting, bob in accounting will go "weird, autofill isnt working, ill copy/paste it".
that is not a possibility with a passkey.
This is where Passkeys shine, in an edge-case user that is neither of the two most common user types. Basically a unicorn situation.
you must not work in regular corporate environments. this happens all the time.
yes, they know how to hit the big "copy" button but don't know how to debug an extension.
take a year or two to work security (or general IT support) in a non-tech-company corporate environment, and get ready to have your socks blown off. people become exceptionally literate with things they interact with all day (excel is great example of this) yet have no idea that google.example.com isn't an official google website.
