To avoid getting locked out you could add 2-3 passkeys from different providers to each account. And/or use a passkey provider that allows backups, and back up your keys. But I doubt many people will have the discipline to do either of that.
Btw this predates passkeys which should perhaps be the way to go from now on.
> 2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.”
Does that mean that GOOD must be a 3rd party identity provider like Facebook, Apple, Google etc?
When you insert the login code on BAD, BAD uses it to finish the login process on GOOD that they started “on your behalf”.
1. you got login credentials at GOOD
2. you're using the same email address there
They then tell you GOOD will send you a code that you have to enter on their website.
Then they enter your Email on GOOD and request a reset, which sends a mail with a code to you.
You then enter the code on their website.
Now that they have the code they can enter it on GOOD and they have your account.
To be fair, can we blame them? There are so many legitimate flows that redirect like it’s a sport. Especially in payments & authn, which is where it’s most important. Just random domains and ping pong between different partner systems.
I always reject attestation requests and I don't recall ever having been refused, so if this was a real problem it seems like I ought to have noticed by now.
The protocol normally allows you to omit the attestation, but they worked around an extra call after a successful registration flow that sends you to an error page if your FIDO2 passkey isn't from one of these large approved vendors: https://learn.microsoft.com/en-us/entra/identity/authenticat...
I found out by trying to prototype my own FIDO2 passkey, and losing my mind trying to understand why successful flow that worked fine on other websites failed with Microsoft. It turns out, you are not allowed to do that.
It started with OneNote web a couple years ago. Every day that gave a popup "Your session needs to be refreshed) and it would reload all over again. Microsoft don't bother to make a OneNote desktop app for my platform and the web version is really terrible anyway (you can only search in one tab, not a whole notebook). So I moved to self-hosted Obsidian which I'm really happy with. Now I can basically see myself typing in a note from another client.
But replacing Microsoft for email is another topic.
B2C I would expect more latitude on requiring attestation.
I think it's reasonable to have attestation for the corporate use case. If they're buying security devices from a certain vendor, it's reasonable for their server to check that the person pretending to be you at the other end is using one of those devices. It's an extra bit of confidence that you're actually you.
I once knew a guy who refused to let his office computer go to sleep just to avoid having to enter his password to unlock his computer. He was a really senior guy too, so IT bent to allow him do this. What finally made him lock his computer was a colleague sending an email to all staff from his open outlook saying “Hi everyone, it’s my birthday today and I’m disappointed because hardly anyone has come by to wish me happy birthday”. The sheer mortification made him change his ways.
I do remember explicitly telling them (because of course having agreed to do this they have no idea how and need our instructions) not to enable attestation because it's a bad idea, but you seem to be saying that it'll somehow be demanded (and then ignored) anyway and that was not my experience.
So, I guess what I'm saying here is: Are you really sure it's demanded and then ignored if you turn it off from the administrative controls? Because that was not my impression.
If you refused to provide make and model, IIRC you would fail the check whether enforcement was enabled or not. Then if enforcement was enabled and your AAGUID didn't match the list, you would see a different error code.
Either way, you're sending over an attestation. They understandably forbid attestation format "none" or self-signed attestations. It's possible that this has changed, but the doc page still seems to say they won't accept a device without a packed attestation, it's only that the AAGUID check can currently be skipped.
I understand the value of attestations in a corporate environment when you want to lock down your employees' devices. But that could simply have been handled through a separate standard for that use case.
https://github.com/keepassxreboot/keepassxc/issues/10407
> To be very honest here, you risk having KeePassXC blocked by relying parties
But having a choice about how you store your credentials shouldn't depend on the good faith of service providers or the spec authors who are doing their bidding anyway. It's a bit similar to sideloading apps, and it should probably be treated similarly (ie, make it a right for users).
People forget that one of the purposes of authentication is to protect both the end user and the service operator.
Pretty much every service out there has "don't share credentials" in their ToU. You don't have to like it, but you also don't have to accept the ToU.
My point was that freedom is not an absolute, it's balanced against other freedoms. It's hard to tell whether you agree with that or not.
Attestation provides a guarantee that the credential is stored in a system controlled by a specific vendor. It’s not “more” or “less” secure, it’s just what it literally says. It provides guarantees of uniformity, not safe storage of credentials. An implementation from a different vendor is not necessarily flawed! And properties/guarantees don’t live on some universal (or majority-applicable) “good-to-bad” scale, no such thing exists.
This makes sense in a corporate setting, where corporate wants predictability and uniformity. It doesn’t make sense in a free-for-all open world scenario.
I guess it’s the same nearsighted attitude that makes companies think they want to stifle competition, even though history has plenty of examples how it leads to net negative effects in the long run despite all the short term benefits. It’s as if ‘00s browser wars haven’t taught people anything (IE won back then - and where is it now?)
How is it a fallacy? The rate of account compromises is a real metric that is affected by how good security there is for accounts.
Yes, the rate of account compromises is a metric we can define. But attestation doesn't directly or invariably improve this metric. It may do so in some specific scenarios, but it's not universally true (unless proven otherwise, which I highly doubt). In other words, it's not an immediate consequence.
It could help to try to imagine a scenario where limited choice can actually degrade this metric. For example, bugs happen - remember that Infineon vulnerability affecting Yubikeys, or Debian predictable RNG issue, or many more implementation flaws, or various master key leaks. The less diverse the landscape is, the worse the ripples are. And that's just what I can think of right away. (Once again, attestation does not guarantee that implementation is secure, only that it was signed by keys that are supposed to be only in possession of a specific vendor.)
Also, this is not the only metric that may possibly matter. If we think of it, we probably don't want to tunnel vision ourselves into oversimplifying the system, heading into the infamous "lies, damned lies, and statistics" territory. It is dangerous to do so when the true scope is huge - and we're talking about Internet-wide standard so it's mindbogglingly so. All the side effects cannot be neglected, not even in a name of some arbitrarily-selected "greater good".
All this said, please be aware that I'm not saying that lack of attestation is not without possible negative effects. Not at all, I can imagine things working either way in different scenarios. All I'm saying that it's not simple or straightforward, and that careful consideration must be taken. As with everything in our lives, I guess.
The meeting was about him unable to test the APK of the new version of their mobile app. He felt embarrassed, his mobile phone is enrolled in the MDM scheme that disallows side-loading of apps.
What I am trying to say is that assuming users are stupid carries a non-negligible risk that you will be that stupid user one day.
This is far from very obvious, especially given that Apple have gone out of their way to not provide attestation data for keychain passkeys. Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.
There are a bunch of service provider contexts where credential storage attestation is a really useful (and sometimes legally required!) feature.
Drop attestation from passkeys, and I become a promoter. Keep it, and I suggest people stay away.
If it's not something anyone intends to use on public services, this should be uncontroversial. Dropping attestation simplifies implementation, and makes adoption easier as a result.
> It seems like the requirements already diverged.
No, the requirements are _contextual_. This isn't a new idea.
What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?
I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec.
Passwords suck. It's depressing that otherwise good alternatives carry poisonous baggage.
If you make something possible, it will be used.
Sure, but that's not without tradeoffs. I come back to:
> Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.
That kind of thing can make a huge difference once this standard starts becoming e.g. required for government procurement.
I should need to install an enterprise authenticator app, which speaks webpki-enterprise, if you want to enable that shit.
Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to).
Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"?
A misguided administrator is very likely to think "They can't use a malicious device to access our service".
What's the benefit for a private service?
Austria's governmental ID is linked to 5 approved tokens only.
We have already been through this with many services suddenly demanding that you give them your phone number "for security".
Here's a Fido2 member (Okta) employee saying "If keepass allows users to back up passkeys to paper, I think we'll have to allow providers to block keepass via attestation." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
All because passkeys backup is deemed "too unsafe and users should never be allowed that feature, so if you implement it we'll kick you out of the treehouse."
The authoritarian nature of passkeys is already on full display. I hope they never get adopted and die.
I'll post the same response I replied to other on a different thread:
Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues).
1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice
2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world?
3) There is no known synced passkey credential manager that attests passkeys.
tl;dr attestation does not exist in the consumer synced passkey ecosystem. Period.
You may have "been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice", but as soon as one such credential manager allows export that becomes "something that I have previously rallied against but rethinking as of late because of these situations".
There may not currently be attestation in the consumer synced passkey ecosystem, but in the issue thread you say "you risk having KeePassXC blocked by relying parties".
The fact that that possibility exists, and that the feature of allowing passkeys to be exported is enough to bring it up, is a huge problem. Especially if it's coming from "one of the most vocal proponents of synced passkeys never being attested", because that says a lot about whoever else is involved in protocol development.
> The fact that that possibility exists,
The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago.
Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection, the security minded folks who have to adopt this stuff are going to remember when someone in the industry publicly said "if you don't use a YubiKey/iPhone/Android and connect to the internet, ~someone~ might ban you from using your authenticator of choice."
This is already possible today. And since it's a completely open ecosystem, you can even build your own credential manager if you choose!
>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 is exactly why we need truly open standards, so people who believe they are acting for the greater good can't close their grubby hands over the ecosystem.
That's not the right question. The right question is "what companies would be using passkey's if there was attestation on their security". To answer that question, you might look at the answer for a similar one on X509: "would we be doing banking over http if X509 didn't have attestation?".
Every time I’ve seen them actually attack user freedom, there was an embarrassingly obvious business angle. Like Chrome’s browser attestation that was definitely not to prevent Adblock, no sir.
But I fear it's worse. Based on how past open standards played out, I find it believable they do care - that there won't be an open ecosystem of password managers.
> But they’ve shown no evidence of hating user freedom on principle.
Yes, they did, just see Microsoft's crusade against Linux and the origin of the "embrace-extend-extinguish" term.
I recommend reading the MDN docs on Webauthn, they’re surprisingly accessible.
> Yes, they did, just see Microsoft's crusade against Linux and the origin of the "embrace-extend-extinguish" term.
The whole point of the trial that term came from was that Microsoft explicitly saw Linux as a material threat to their business. What threat are Google quashing by preventing you from using passkeys they don’t control?
I agree, why would BigTech care about those dozens of users. Screw those guys, they can use our password manager or they can get lost, we don't need them!
Because big tech loves control. Just because you can't see the angle yet, it doesn't mean there isn't one now, or won't be one later. It has been shown time and time again that they will take all the freedom away from you that they can.
Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time.
> Even if there wasn't already an example, it's easy to turn control into a revenue stream at a later time.
I think you’ll have to justify or qualify this a bit. If Google forces every website on Chrome to have a red background, how do they turn that control into a revenue stream later on?
Chrome has already started kicking off extensions, see ublock.
I can't divine the future about how they will further their income streams.
As for blocking things that block ads; if you can’t see the monetary incentive for Google there then I don’t know what to tell you.
I didn’t ask you to divine the future. I said “I’ve not seen them do X without trying to get Y” (a statement about the past), and you still haven’t given me a remotely credible example.
Where's the direct monetary incentive to interfere with end users installing a modified Android image? What about SafetyNet?
At absolute minimum you can use it to influence the perception of your brand as being the gold standard.
Bots using a custom password manager to share logins.
Now the Yubikey is just an API you can call, websites cannot tell the difference. You can't export keys, but a bot can add new keys after using existing keys to log in.
Making staff look like idiots in front of clients is a resume-generating-event.
His reply does give one aspect of it: passkey's are fragile. To be secure, they can't be copied around or written down on a piece of paper in case you forget, so when the hardware they are stored on dies, or you lose your Yubikey or is as he described the PC re-imaged, all the your logins die. That will never fly, and it's why passkeys are having a hard time being adopted despite them being better in every other way.
Passkey's solution to that is to make them copyable, but not let the user copy them. Instead someone else owns them, someone like Google or Apple, and they will do the copy to devices they approve of. That will only be to devices they trust to keep them secure I guess. But surprise, surprise, the only devices Apply will trust are ones sold to you by Apple. The situation is the same for everyone else, so as far as I know bitwarden will not let you copy a bitwarden key to anyone else. Bitwarden loudly proclaims they lets you export all your data, including TOTP - but that doesn't apply to passkeys.
So, right now, having a passkey means locking yourself into proprietary companies ecosystem. If they company goes belly up, or Google decides you've transgressed one of the many pages of terms, or you decide to move to the Apple ecosystem again you lose all your logins. And again, that won't fly.
The problem is not technological, it's mostly social. It's not difficult to imagine a ecosystem that does allow limited, and secure transfer and/or copying of passkeys. DNS has such a system for example. Anyone can go buy a DNS name, then securely move it between all registrars. There could be a similar system for passkeys.
Passkeys have most of the bits in place. You need attestation, so whoever is relying on the key knows it's secure. The browsers could police attestation as they do now for CA's. We have secure devices that can be trusted to not leak leak passkeys in the form of phones, smartwatches, and hardware tokens. But we don't have a certification system for such devices. And we we don't have is a commercial ecosystem of companies willing to sell you safe passkey storage that allows copying to other such companies. On the technological front, we need standards for such storage, standards that ensure the companies holding the passkeys for you couldn't leak the secrets in the passkeys even if they were malicious.
We are at a frustrating point of being 80% of the way there, but the remaining 20% looks to be harder than the first 80%.
Passkeys could have been an overall boon to society. But with attestation restricted to a set of corporate-blessed providers it is a Faustian bargain at best.
There is no attestation in the consumer synced passkey ecosystem. Period.
How do you expect a single person to be able to make an authoritative statement like that?
> The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup).
Those are the solutions I'm familiar with; there may be others. If Android and Windows don't already solve this problem in similar ways--which they might!--it sounds like an open opportunity for them.
Edit: sure enough, Android supports it: https://support.google.com/chrome/answer/13168025?hl=en&co=G...
As does Windows: https://blogs.windows.com/windowsdeveloper/2024/10/08/passke...
but I don't think attestation per-se is bad, if you are a employee from a company and they provide you the hardware and have special certification requirements for the hardware then attestation is totally fine
at the same time normal "private" users should never exposed to it, and for most situations where companies do expose users to it (directly or indirectly) it's often not much better then snake oil if you apply a proper thread analysis (like allowing banking apps to claim a single app can provide both the login and second factor required by law for financial transactions, except if you do a thread analysis you notice the main thread of the app is a malicious privilege escalation, which tend to bypass the integrity checks anyway)
But a lot of the design around attestation look to me like someone nudged it into a direction where "a nice enterprise features" turns into a "system to suppress and hinder new competition". It also IMHO should never have been in the category of "supported by passkey" but idk. "supported by enterprise passkey only" instead.
Through lets also be realistic the degree to which you can use IT standards to push consumer protection is limited, especially given that standard are made by companies which foremost act in their financial interest, hence why a working consumer protection legislation and enforcement is so important.
But anyway it's not just the specific way attestation is done, it's also that their general design have dynamics push to a consolidation on a view providers, and it's design also has elements which strongly push for "social login"/"SSO" instead of a login per service/app/etc. i.e. also pushes for consolidation on the side of login.
And if you look at some of the largest contributors you find
- those which benefit a ton from a consolidation of login into a few SSO providers
- those which benefit from a different from a login consolidation (consolidation of password managers) and have made questionably blog entries to e.g. push people to not just store password but also 2FA in the same password manager even through that does remove on of the major benefits of 2FA (making the password manager not a single point of failure)
- those which benefit a ton if it's harder for new hardware security key companies, especially such wich have an alternative approach to doing HSKs
and somehow we ended up with a standard which "happened" to provide exactly that
eh, now I sound like a conspiracy theorist, I probably should clarify that I don't think there had to be some nefarious influence, just this different companies having their own use case and over fitting the design on their use case would also happen to archive the same and is viable to have happened by accident
Perhaps I'm missing something, but I do think hardware "attestation per-se is bad. Just look at the debacle of SafetyNet/Play Integrity, which disadvantages non-Google/non-OEM devices. Hardware attestation is that on steroids.
As for corporate/MDM managed environments, what's wrong with client certificates[0] for "attestation"? They've been used securely and successfully for decades.
As for the rest of your comment, I think you're spot on. Thanks for sharing your thoughts!
I feel like I'm doing something stupidly wrong or missing a prompt somewhere, or maybe UX is just shitty everywhere, but if I, a millennial who grew up programming and building computers, struggle with this, then I don't expect my mom, who resets her password pretty much every time she needs to sign into her bank, to get it to work.
I haven't invested more time in this because if it's so unusable for me as an engineer, it's a non-starter for the general public.
Go to the playstation. Can’t login anymore. Passkey not supported.
I use Yubikeys, and passkeys just work. On Chrome, Firefox and Safari, both on macOS and Linux (specifically Alpine). I also tried with iPhones (for my family), and it also just works.
I haven't tried using an Android device, is it what you are trying?
As I said, it just works with iPhones and Yubikeys.
It's too early for grandma to use, IMO.
The only relevant Bitwarden setting appears to be "Ask to save and use passkeys" under Notifications. I do turn off the browser's built-in password manager, though I believe anything else relevant I have at default. If you have those and they still aren't getting saved, then I'm at a loss, but wish I knew why they don't work for you. In Bitwarden, you can see if there's a passkey saved in an entry, as the creation timestamp is shown right under the password field and editing an entry also allows deleting a passkey.
Depends on the brand of the passkey i think.
The presence of other attestation types in the spec allows passkeys to replace the use of other classes of authentication that already exist (e.g. smartcard). For example, it's very reasonable for a company to want to ensure that all their employees are using hardware Yubikeys for authentication. Furthermore, sharing the bulk of implementation with the basic case is a huge win. Codepaths are better tested, the UIs are better supported on client computers, etc.
The presence of attestations in the spec, does not impinge on user freedom in any meaningful way.
I wish there was a stronger differentiation between syncable and device-bound passkeys. It seems like we're now using the same word for two approaches which are very different when it comes to security and user-friendliness.
And yes, giving granny unsyncable passkeys is a really bad idea, for so many reasons.
But there is no difference. I'd prefer if services just let me generate a passkey and leave it entirely up to me how I manage it. Whoever setup granny's device should have done so with a cloud based manager.
I think Google tries to make some confused distinction, or maybe that has more to do with FIDO U2F vs FIDO2. There you can add either a "passkey" or a "security key", but iirc I added my passkey on my security key so... yeah
I'd imagine a convincing enough modal would do the trick though, in a lot of cases.
if the BAD site itself looks legit, and has convinced a user to do the initial login in the first place, they won't hesitate to lie and say that this 2-factor code is part of their partnership with google etc, and tells you to trust it.
A normal user doesn't understand what is a 2factor code, how it works, and such. They will easily trust the phisher's site, if the phisher first breaks the user and set them up to trust the site in the beginning.
What google does is to send a notification to the user's phone telling them someone tried to access their account if this happened (or any new login to any new device you previously haven't done so on). It's a warning that require some attention, and depending on your state of mind and alertness, you might not suspect that your account is stolen even with this warning. But it is better than nothing, as the location of the login is shown to you, which should be _your own location_ (and not some weird place like cypress!).
the 2FA code in this case is in the email, not via an app. This email is triggered by BAD on their end, but it is sent by GOOD.
If the 2fa is _only_ via the authenticator app, then the BAD will need to convince the user to type in that 2fa code from the app into the BAD site (which is harder, as nobody else does this, so it should raise suspicions from the user at least).
The prompts that show where the login is coming from are useless, too, because mapping from IP addresses to geographical locations is far from perfect. For example, my legit login attempts showed me all over my country map. If I’m in a corporate VPN already, its exit nodes may also be all over the map, and your legitimate login from, say, Germany may present itself as coming from Cyprus, which is shady as fuck.
If I seek to implement 2fa for my own service and have it be not theater and resistant to such phishing attacks, it gets difficult real fast.
- open website
- if not already logged in, log in to 1Password
- autofill password
- autofill TOTP
Now:
- open website
- if logged in to 1Password the Use Passkey usually shows up
- if not:
- log in to 1Password
- choose use passkey
- this almost always does nothing
- choose “use other method”
- choose “password”
- autofill that
- now there is another dialog to choose the 2fa method, choose Authenticator
- autofill that
Apple Passwords now sufficiently good to replace 1Password for me and I’m slowly transitioning.
I don’t mind subscription models per se but there was something about subscription for your own passwords that made me refuse to jump the fence when 1Password switched to that model.
Would be a bit faffy if you’re a Chrome user.
Let me see if I can get it again
The implementation in Chromium browsers (I use Arc, so I can't speak to Chrome itself) is basically a chunkier-looking 1Password.
I also have a bunch of stuff in 1Password that doesn’t have a home in Apple Passwords, which would be a problem.
And yes, Chrome with Apple Passwords is annoying. At work I’m forced to use Chrome for some things, and I’ve been dabbling with Apple Passwords. Every time I launch the browser I have to put in a code to link the extension with Passwords. It’s very annoying.
2. If you get this often, why do you use 1Password, honest question.
1Password used to work decently well before 2020. Now I have ~ 2k items in 1Password, distributed among two accounts (work and personal). Additionally, my spouse and I have a shared 1Password vault via the Family plan.
There’s no way I’m going to migrate 2k items and two dozen devices to another vendor. If there were one that met my requirements to begin with.
For example, are my 2FA seeds going to migrate properly? How about the tags, attachments, sections, subsections, security questions and answers, inline Markdown notes, the HIBP integration, built-in overrides to fix known broken websites, workarounds I’ve learned for unfixed websites, shared vaults, recovering lost access to shared vaults, syncing, templates, custom integrations that I maintain [0], personal scripts, etc. etc.
Will it still be able to auto-fill into a web page? Into shitty, broken web pages? On Linux? On my Linux phone?
At the scale and depth at which 1Password is currently integrated into my spouse’s and my life, it’s difficult to consider migration anything less than a full weekend project.
I regret letting my spouse and myself lock into 1Password before it enshittified.
Now that I’m so paranoid about this, and not remembering which sites I have them for, I always dismiss the passkey prompt, then have to click several more times to get to the password login and fill it in with my password manager.
No, at least not on its own. Let's not repeat the mistakes.
Password managers are the way to go and ONLY FOR RARE EXCEPTIONS we should use dedicated MFA, such as for email-accounts and financial stuff. And the MFA should ask you to set up at least 3 factors and ask you to use 2 or more. And if it doesn't support more or less all factors like printed codes, OS-independent authenticator apps and hardware keys like yubikey, then it should not be used.
Such as finding a dinosaur fossil of your families name clan.
Bitwarden the password manager includes a full passkey implementation, which doesn't involve any MFA.
No: - I can always export and import all my passwords from/into my password manager - My passwords always work independently of a password manager or any specific app/OS/hardware
That is not true for passkeys and makes them much more like tokens. Of course they don't have to be used in MFA, just like passwords.
This is only about your first paragraph, it doesn't affect your second.
Counter-example: I can write a password manager that will not allow you to export/import passwords.
There are cases where bitwarden doesn't work but chrome for example does. Easy to Google up.
For passwords however, I never heard of a case where a website only accepts passwords from a specific password manager - and how could they even do that right?
If the website accepts a password, then it can't prevent you from using the password manager you want. But if the website accepts FIDO2 passkeys, it's the same thing, isn't it?
For example: https://www.w3.org/TR/webauthn-2/#dictdef-authenticatorselec...
> If the website accepts a password, then it can't prevent you from using the password manager you want. But if the website accepts FIDO2 passkeys, it's the same thing, isn't it?
Unfortunately not...
Those sound like requirements similar to those that can be enforced with passwords. My company enforces an SSO system with an MFA scheme that is controlled by the IT department. I can use my password manager for the password part, but I must use the mandatory MFA app.
In that sense, I am not sure it is so different from passkeys?
> In that sense, I am not sure it is so different from passkeys?
Yes, if it means "company specific SSO* and a company chooses to force you to use the hardware they decided on, then that is in fact not very different from the passkey constraints.
Passkeys is an interface between your password manager and a website without all the fluff with filling or copy-pasting passwords.
I don't love them. I don't love passwords either.
But while I don't fear passwords, I fear passkeys. The reason is that it makes the tech even more intransparent. My password manager stops working, completely dies or I can't use it anymore for other reason? No problem, I can fallback to a paper list of passwords if I really have to. This transparency and compatibility is more important than people think.
Passkeys lack that. They can be an interface like you described, but only if everyone plays along and they can be exported. But since there is no guarantee (and in practice, they often cannot be exported either) they are not a replacement for passwords. They are a good addition though.
Unfortunately, many people don't understand that and push for passwords to begone.
It's literally something like
hnkTKS7h2WCOBr3CxSKM51cSVKSkiKOSlQsMhtRZ0CU
And I would agree with that argument.
Also they are too complicated for an ordinary user. A physical key is much simpler and doesn't require any setup or thinking, and can be used on multiple devices without any configuration. And doesn't require a cloud account.
Passwords have always been bad. The problem is that users can't remember them. So they rotate, like, 3 passwords.
Which means if fuckyou.com is breached then your bank account will be drained. Great.
On top of that, the three passwords they choose are usually super easy to guess or brute force.
With a password manager, users only need to remember one password, which means they can make said password not stupid. You can automatically log in too with your new super secure passwords you never need to see.
Its the perfect piece of software. Faster, easier, more secure, with less mental load.
I don't, but even if I do, the simple fact remains that remembering one password is easier than 300.
If you have to remember 300 passwords, youre gonna choose 'password1' - 'password300'. Because we're not living hashmaps.
But with one password, I can easily make it even 40 characters and remember it. And anybody can do that.
If you DON'T use a password manager, you don't solve the problem of "everything is lost". Because people just reuse passwords as noted above.
So Experian gets breached, which is WAYYYYY more likely than your encrypted password manager getting breached, and now your bank is also open, and your Gmail, and your IRS.gov. whoops.
> does this assume you only use one device that you will always use
No, password managers work on all your devices and auto sync. How is it done so securely and without any hiccups? Because they're super simple pieces of software.
You just take the passwords, derive a key from the master password, and encrypt all the passwords. Then dump it in whatever online storage.
I could write a password manager in a couple hours.
I think you're rejecting good solutions out of hand.
Meanwhile...millions of users trusted LastPass. Twice.
I’m not going to rely on myself never making a mistake. I want a solution that protects me even during stressful moments where I have a lapse of judgement and forget to check.
You might find the KeePassXC docs about the feature [0] to be informative.
If you're going to complain that all a phisher has to do to capture a password is create a website with the same title as the official one, then my reply would be something like "Duh. That's what the browser plugin is for.".
[0] <https://keepassxc.org/docs/KeePassXC_UserGuide#_auto_type>
[1] ...optionally, and on by default...
I’m absolutely looking for a browser plugin. I would refuse to use an auto-type feature that only checks the window title instead of, as a browser plugin would do, the site’s domain.
I was mentioning how auto-type worked because it's useful information for those who either are unwilling to use a browser plugin, or are like myself and simply have no need for one.
In general, opening a malicious URL exposes the user to unnecessary risk, so the correct solution is not to assume the user has visited a malicious site (since that would already be high-risk), but rather to prevent opening of malicious URLs. The most obvious solution is to treat any untrusted content as questionable. So I very carefully examine every domain I visit - as I say to my kids: have a model about who owns the computer you're talking to. Domains matter.
Now, this works for me. I'm not cognitively impaired, I have high conscientiousness, probably from working in military and classified defense contexts way back when, but I'm not really sure to be honest, could just be my personality. But it works for me.
I get that you want that extra safeguard, but it's just not a dealbreaker for me, especially since I'm highly suspicious of browser add-ons and the security implications they bring in. I guess I'm just extremely selective about what add-ons I'll use.
/me wonders if this is a "recommend me a nice open source, offline password manager" question in disguise.
That was years ago, so I’m going to check it out again. Thanks for the pointer.
Update: One thing that stands out immediately is a confusing mess of three different projects, two of them unmaintained, which all call themselves KeePassX or KeePassXC, sometimes linking to each other’s documentation. How do I even tell I’m facing the correct KeePass(X(C)?)? project?
Yes, I’ll figure it out eventually but until then, it’s confusing. Also, if a password manager project needs to be forked over and over and over again (how can a holder of the keys to the kingdom possibly go MIA on three different occasions in basically the same project?), then does that tell us something about how the project is governed?
Well, [0] lists a single project called KeePassXC, with [1] as its homepage. Search engines list [1] and [2] as the top results for the query KeePassXC, for whatever that's worth. [3]
> Also, if a password manager project needs to be forked over and over and over again ... then does that tell us something about how the project is governed?
No?
KeePass is Windows-only software. So, some folks decided to write KeePassX, which ran on Linux, OSX, and Windows. They got bored of that after a decade or so, called it quits, and one of the preexisting forks [4] became the widely-used one.
> how can a holder of the keys to the kingdom possibly go MIA on three different occasions in basically the same project?
In addition to the history I wrote above, you are aware that KeePass is still receiving stable releases? According to [5], it looks like 2.59 was released just last month.
EDIT: Actually, where are you getting this "confusing mess of three different projects" from? When I search for "keepass", I get the official home pages for KeePass and KeePassXC as the top two results, the Wikipedia page, and then the Keepass project's SourceForge downloads page. When I search for "keepassx", I get the official homepages for KeePassX and KeePassXC, the wikipedia page, the KeePassXC Github repo, and an unofficial SourceForge project page for KeePassX.
[0] <https://keepass.info/download.html>
[1] <https://keepassxc.org/>
[2] <https://github.com/keepassxreboot/keepassxc/releases>
[3] And -because I'm a Linux user- not only do I have KeePassXC in my package manager, I also know that [1] is listed as its project homepage.
[4] ...which started like four years before KeePassX's final stable release...
[5] <https://sourceforge.net/projects/keepass/files/KeePass%202.x...>
When I searched for `keepassxc`, my search engine ranked eugenesan/keepassxc [0] higher than keepassxreboot/keepassxc [1], so the former was the first that I’d visit. GitHub says that eugenesan/keepassxc is 2693 commits ahead of keepassx/keepassx:master, so I assumed that eugenesan/keepassxc was a legitimate and meaningful fork of keepassx/keepassx. Maybe I’m entirely mistaken, and I was just tricked by a blunder of my search engine and eugenesan/keepassxc is just a random person’s fork? (But then again, if it’s just a random fork, then why does it show up at the top, and why so many commits ahead of keepassx?)
To add even more to the confusion, not only is eugenesan/keepassxc unmaintained, it also points to www.keepassx.org (why?), which in turn says it’s unmaintained, too.
If I was just mistaken and eugenesan/keepassxc is really just a random fork, then my earlier allegations are all moot. Thank you for clearing this up, and also for clarifying that the other (legitimate?) KeePassXC was a preexisting fork (so it would have been difficult for them and possibly even more confusing to users if they had taken over the abandoned KeePassX project).
I've tried DDG, Google, Bing, and Yandex. All of them rank official KeepassXC stuff in the top five results, and -with the exception of Bing- rank it above any other non-Wikipedia results. I didn't see this weird keepassx GitHub fork in the results from any of the search engines I tried.
> When I searched for `keepassxc`, my search engine ranked eugenesan/keepassxc [0] higher than keepassxreboot/keepassxc...
With the greatest of respect, I would expect someone who's sufficiently savvy to know what to do with a GitHub repo in their search result to also be sufficiently savvy to -at minimum- visit the homepage listed in the repo's About blurb and notice that [0] is the very first item in the list of "Latest News". I'd also expect that savvy someone to know to visit the repo's Releases page, notice that there are no published releases, and consider even more intensely that they might not be looking at the software they expected to see.
I can't explain why your search system is ranking this misleadingly-named GitHub repo so highly. AFAICT, noone with the repo owner's email address was ever involved in any public development on KeePassXC.
I’m using Kagi. They say they rely on several third-party search indexes. I can’t see which one they are using for which particular search request. What I do know is that the backends are of varying quality. However, after years and years of using Google (back when their search was still good), I got used to the fact that if they return a GitHub project as a top search result, then that project was usually meaningful.
> With the greatest of respect, I would expect someone who's sufficiently savvy to know what to do with a GitHub repo in their search result to also be sufficiently savvy to -at minimum- visit the homepage listed in the repo's About blurb and notice that [0] is the very first item in the list of "Latest News".
Forks sometimes don’t update the About blurb that they inherit, and I think that that’s exactly what happened in the bogus repo.
> I'd also expect that savvy someone to know to visit the repo's Releases page, notice that there are no published releases, and consider even more intensely that they might not be looking at the software they expected to see.
In this case, however, the Releases section said “13 tags.” Some projects don’t use GitHub’s Releases feature at all, and rely only on Git tags. It’s sometimes difficult to spot.
cf. pass(1)[0][1]
[0] https://www.passwordstore.org/
[1] No, it's not hosted in the cloud (i.e., on someone else's servers) and that's a good thing. It's FOSS and can be compiled for Android/IOS (and has, see [2][3][4], least for Android). The DB (just a GPG store) can also be shared across multiple devices.
[2] https://f-droid.org/packages/app.passwordstore.agrahn/
[3] https://play.google.com/store/apps/details?id=dev.msfjarvis....
[4] Not sure about IOS versions, I don't have any Apple devices.
Visiting the bank is fine. But who do you visit to recover your Gmail password?
It can take months and it only guarantees a backup, not full access, but it's better than nothing.
In practice: in my case, anecdotally, they just did it. For some reason owning the backup email account was not enough for the automated workflow to unlock my account, but sending a letter threatening to sue under the GDPR somehow changed their minds.
There are lots of attack patterns. That is one. I am not certain I believe it is very likely, because (a) I think "sign-in partner" is obvious bullshit, and (b) I don't understand why I would never enter a code into the wrong website. I believe it can be possible, but...
> Passkeys is the way to go. ... I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.
... I do not agree your story is justification for passkeys, or for letting banks trust passkeys for authentication purposes. I'd rather she not lose access to banking services in the first place: I don't think banks should be allowed to do that, and I do not think it should be possible for someone to "steal all her money" so quickly -- Right now you should have at least several days to fix such a thing with no serious inconvenience beyond a few hours on the phone. I think it is important to keep that, and for banking consumers to demand that from their bank.
A "granny" friend of mine got beekeeper'd last year[1] and her bank reversed/cancelled the transfers when she was able to call the next say and I (local techdude) helped backup/restore her laptop. I do not think passkeys would helped and perhaps made things much worse.
But I don't just disagree with the idea that passkeys are useful, or even the premise of a decision here between losing all their money and choosing passkeys, I also disagree with your priors: Having to visit a bank branch is a huge inconvenience for me because I have to fly to my nearest. I don't know how many people around here keep the kind of cash they would need on-hand if they suddenly lost access to banking services and needed to fly to recover them.
I think passkeys are largely security-theatre and should not be adopted simply if only so it will be harder for banks to convince people that someone should be able to steal all their money/access with the passkey. This is just nonsense.
[1]: seriously: fake antivirus software invoice and everything, and her and her kid who is my age just saw the movie in theatres in like the previous week. bananas.
Now replace email a with text message sent from a short-code.
Then the banks wanted you to use the dongle to verify yourself on phone and it all went downhill from there.
That's what phishing is predicated on, and it seems to be successful enough.
You and I think they are bullshit, but ... the problem is that bullshit is sometimes genuine.
I have got tired of how many times in recent years I have seen things that looked like phishing or had obvious UX-security flaws and reported them only to have got a reply from customer service that the emails and sites were genuine and that they have no intention of improving.
If janky patterns is the norm, then regular users will not be able to recognise the good-but-janky from the scams.
It's looks almost the same as the log-in-with-big-tech flow that users are already used to.
> and (b) I don't understand why I would never enter a code into the wrong website. I believe it can be possible, but...
You enter it on the website you are trying to log into and where you initiated the action, which in this scenario is the BAD website.
Nearly every website tries to offer Google or Microsoft based sign in, "sign in partners" are commonplace.
My problem with passkeys is that there is no hardware attestation like there is with Yubikeys and similar.
This means for security conscious applications you have no way of knowing if the passkey you are dealing with is from an emulator or the real-deal.
Meanwhile with Yubikeys & Co you have that. And it means that, for example people like Microsoft can (and do) offer you the option to protect your cloudy stuff with AAGUID filtering.
And similar if you're doing PIV e.g. as a basis for SSH keys, you can attest the PIV key was generated on the Yubikey.
You can't do any of that with passkeys.
Device-bound passkeys which are used in workforce / enterprise scenarios are typically attested.
Attestation does not exist for consumer synced passkeys by design. It is an open ecosystem.
And how do you access your password manager when your computer is locked ?
[0] My daily driver OS is https://qubes-os.org
The problem being exploited by BAD is that your login account identifier (email in this case) is used in both GOOD (and BAD - accidentally or deliberately orchestrated), and 2-factor does not prevent this type of phishing.
Isn't this the same thing as BAD asking, let us know the code i.e. password that GOOD gave you? Why would one be inclined to give BAD (i.e. someone else) this info?
You get an email, providing you with a phishing link for miсrosoft.com (where the apparent c is actually the cyrillic "s", so BAD). In the background, they initiate a login to microsoft.com (GOOD), who then send you a 6 digit code from the actual microsoft.com. If you were fooled by the original phishing website, you have no reason to doubt the code or not enter it.
This point means the user is not paying attention: 1) User goes to BAD website and signs up. Steps 2-7 wouldn't be possible without 1.
"Click a link in the email" is really bad because it's very difficult to know the mail and the link in it are legitimate. Trusting links in emails opens to door to phishing attacks.
The company doesn't care either because fraud is just the cost of doing business- ease of ordering> security.
abc.com
the link in the email is abc.com
track.monkey.exe/sus/path/spyware?c=behhdywbsncocjdb&b=ndbejsudndbd&k=uehwbehsysjendbdhjdodj
or something 2x–3x longer
And the answer was, I can find out if the email is from abc.com by looking at the link, which should also be abc.com
I don't click in "track.monkey.exe". I don't click tracking links. I pay a lot of money for my newsletter provider because I can turn off (most) tracking links.
Many sites do offload 100% of their emailing to 3rd party trackers. Therefore nobody can use those sites without engaging in 3rd party tracking. Therefore these sites have created an environment favorable for this scam vector.
Track someone else.
The problem is that I can physically show up at my local bank branch or at my job's IT helpdesk to get my account back, but I can't show up at the Googleplex or at Facebook's or Xitter's HQ and do the same. Device bound passkeys are very error prone for the latter scenario, since users will fail to account for that case.
With Amazon's live chat, someone was able to get into my account by providing an address in the same city as the destination of my latest Amazon order.
You see this with 2FA since "sorry lol you've lost your account forever" isn't an option, and it's trivial for users to lose their 2FA key unlike, say, access to their email.
Even services that use login via emailed link need to do it because people do lose email access. Far too many people use the email provided by their ISP as their only email service, which can be very bad if they move to someplace that ISP does not serve or simply want to switch to another ISP in their current area.
And once you set up a customer service pipeline for it, you might accidentally create a backdoor that's far worse than forgot-my-password email verification: https://medium.com/@espringe/amazon-s-customer-service-backd...
Email account access is the closest thing we have to ubiquitous identity on the web. Users that truly lose access to their email account are in a catastrophic situation before they even think of whether they can access your service.
So, I guess you set up some "emergency users". And maybe if you lose access to your account, you get customer support to mark your account as lost which sends an email to the address that you have on file (in case it's an attack started by someone other than the user).
And I suppose if N days pass without any login, one of your emergency users can generate a credential that they can pass to you to recover your account?
That and Apple will give you a very long one-time password meant to be printed that can restore access as well. This one is in a third undisclosed location for me.
Peope do read, if the email is short
On what grounds you say people dont read? Any evidence?
This premise seems flawed.
How can you possibly know from experience that something is “very understandable” if the only brain you have is your own?
How do you anticipate how other people with brains different from yours are going to behave in situations of cognitive impairment or extreme stress, things that happen in the real world?
But I am speaking of myself only. From experience receiving well designed message comparing to the experience with badly designed messages.
I am a data point of evidence supporing my view. The opinion that "people don't read" is a complete speculation, without convincing evidence.
The real problem that many services simply not include the warning in the message.
It was that “[t]hey only read what they need to finish what they are currently trying to do.”
Those are two different claims.
Do not share the code 3456
The code should be in the same font as the rest of the text.
I’m an avid reader. But there are limits to what I can process, and our world has become so full of noise that it has become a coping strategy for brains to selectively ignore stuff if they feel it’s not important at the moment. That effect becomes even more pronounced as the brain deteriorates with age.
And more so if you receive them constantly.
But of course, you are entitled to your opinion, even if it's wrong.
(The OP says one time codes are worse than passwords. In case of fishing passwords fail the same way as one time codes.)
I was also sarcastic/provocative even in the prev comment, saying the GOOD site always includes a warning with the code making the attack impossible. A variation of the attack is very widely used by phone scammers: "Hello, we are updating intercomm on your appartment block. Please tell us your name and phone number. Ok, you will receive a code now, tell it to us". Yet many online services and banks still send one time codes without a warning to never share it!
The fishing point may also be used in defence of one time codes: if the GOOD service was using passwords instead of one time codes, the BAD could just initiated fishing attack, redirecting the user to a fake login page - people today are used to "Login with" flow.
1) User goes to BAD website and signs up (with their user and password). BAD website captures the user and password
2) BAD website shows a fake authentication error, and redirects to GOOD website. Users is not very likely to notice.
3) BAD uses user and password to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.
OK, with a password manager the user is more likely to notice they are in BAD website. Is that the advantage?
Passkeys are stronger here because you can’t copy and paste a passkey into a bad website.
I am waiting for the era when using passkeys is not depending from some big tech company.
You can choose any credential manager you want to store your passkeys.
My expectations for how long I intend to be alive and using the internet is much longer than my expectations for the continued operation and service of any particular passkey management software.
I already had to jump ship from LastPass after they were hacked. Imagine if they hadn't allowed me to migrate my passwords.
On the rare occasion that my password manager refuses to autofill, I take a step back and painstakingly try to understand why. This happens about once a year or twice.
A bad practice is the shorten the code validity to a few minutes. This cannot really be justified and puts users under stress, which lessens security.
The discussion around passkeys, who is and isn't allowed to store them, almost killed them for me personally. I use them for very, very few services and I don't want to extend it.
I set up a passkey for github at some point, and apparently saved it in Chrome. When I try to "use passkey for auth" with github, I get a popup from Chrome asking me to enter my google password manager's pin. I don't know what that pin is. I have no way of resetting that pin - there's nothing about the pin in my google profile, password manager page, security settings, etc.
The way to go is an encrypted password manager + strong unique random passwords + TOTP 2FA. It's human-readable. Yes, that makes it susceptible to phishing, but it also provides very critical UX that makes it universal and simple.
Especially since Google doesn’t allow you to change your personal default which is what convinced me to go and switch all my accounts off of Google SSO
With a password, I can write it down on a piece of paper and put it in my safe.
One of these systems is not like the other.
On my Windows laptop that is Windows Hello PIN, not sure about other OSs. And it can be disabled.
I wouldn't have minded if we moved to a scheme like SSH logins with public and private keys I own either, that I can store securely but load as I please and again would work well with a local password manager.
it's not quite new, as a dump example depending where in android contacts you click on a address it might always force open google maps (2/3 cases) or (1/3 cases) propelry goes through the intend system and gives users a choice
stuff like that has been constantly getting worse with google products, but it's not like Microsoft or apple are foreign to it
They’re too opaque for my taste and I don’t like them.
Point is, the damage will be likely local to a single or a handful of accounts.
If all the accounts are protected by two factor on my phone and I lose it or it bricks, then I'm done. It will be a total mess with no paths to recover, except restarting literally everything from scratch.
I have Google Auth app on my phone and every few months I consider using it, but then reconsider and stay with passwords.
But granny can't go to a bank because they closed down most of their offices. Since 99% of what you need a bank for can be done using their app it no longer made financial sense to have a physical presence in most smaller towns and villages.
Lots of elderly were complaining about this when it happened because they were too lazy to learn how to use the bank apps. Hell, they already started complaining when you could no longer withdraw money at the desk even before they closed down the offices. Apparently even learning to use something as simple as an ATM was too much effort for them.
1) User goes to BAD website.
2) BAD website says “Please enter your email and password”.
3) BAD’s bots start a “Log in with email and password” on the GOOD website using the user’s email and password.
4) BAD now has full access to the user’s GOOD account.
- user has an account on GOOD.COM
- user has saved her password in her browser
- user navigates to BAD.COM
A clickable link sent in email mostly works too, it ensures that the user arrives at GOOD.COM. (If BAD sends an email too, then there is a race condition, but it is very visible to the user.)
Pin code sent in email is not very good when the user tries to log in to BAD.COM.
In the OP's example, the user is logging in to BAD.com intentionally, but his GOOD.com account is still hacked into.
This is a lot harder for the user to catch on to.
It's just an email, and a six digit code they text you.
There is no password in these new flows. They just ask for email or phone and send you a code.
Bad website only needs to ask for an email. It logs into Good with a bot using that email. Good sends you the code. You put the code in bad. Bad finishes the login with that code.
At no point in time is a password involved in these new flows. It's all email/txt + code.
Many sites work like this now. Resy comes to mind.
For a lot of people, dealing with (now mostly digital) bureaucracies is a major stress in life. The biggest one, for some.
Its not just about invonvenience. Its sometimes about losing access to some, and just not having it for a while.
In terms of practical effect, a performance metric for a login system could be "% of users that have access at a given point." There can be a real tradeoff, irl, between legitimate access and security.
On the vendor side.. the one time passwords fallback has become a primary login method for some. Especially government websites.
Customer support is costly and limited in capacity. We are just worse at this than we used to be.
Digital identity is turning out to be a generational problem.
How many HN denizens are the de facto tech support for family members when they can’t login, can’t update, can’t get rid of some unwanted behavior, or just can’t figure stuff out?
I don’t blame them one bit. The tech world has presented them with hundreds of different interfaces, recovery, processes, and policies dreamed up by engineers and executives who assume most of their user base is just like them.
> Website: is this Jimbob' phone
> Hardware: yes
And
> Website: I'll give you a dollar if you tell me something juicy about this user
> Hardware: Give this token to Microsoft and ask them
> Microsoft: Jimbob is most likely to click ads involving fancy cheeses, is sympathetic to LGBTQ causes, and attended a protest last week
With passwords and TOTP codes, I am in control of what information is exchanged. Passkeys create a channel that I can't control and which will be used against me.
(I chose Microsoft here because in a few months they're using the windows 10->11 transition to force people into hardware that locks the user out of this conversation, though surely others will also be using passkeys for similarly shady things).
I don't think you understand the protocol. The attestation object does not mean there is an authenticator attestation.
There is no authenticator / credential manager attestation in the consumer synced passkey ecosystem. Period.
It seems pretty clear that "where possible" parties besides the user are provided with information about the user (ostensibly about their device, but who knows what implementers will use this channel for)... so they can make a trust decision.
It's going to end up being a root-of-trust play, and those create high value targets which don't hold up against corruption, so you're going to end up with a cabal of auth-providers who use their privileged position to mistreat users (which they already do, but what'll be different is that this time around nobody will trust that you're a real human unless you belong at least one member of this cabal).
Folks seem to be hung up on the term "attestation" being in the response of a create call. If you look inside that object, there is another carve out for optional authenticator attestation, which is not used for consumer use cases.
I will keep repeating what I've said in the other comments. There is no credential manager attestation in the consumer synced passkey ecosystem. Period.
Suppose we hatch a conspiracy to take our users out of the "consumer synced passkey system". And into one where you can use the authentication ritual as a channel where you can pass me unique bits re: this user such that we can later compare notes about their behavior.
What about passkeys prevents us from doing this? How do we get caught, and by whom?
1) That would be a whole lot of work, collusion, etc for a very limited scope and outcome, which makes it incredibly unlikely to happen in practice. 2) If a credential manager decides to do shady things that you don't like, you can change your credential manager. That's the beauty of an open ecosystem. 3) There are much easier ways to track users online...(unfortunately)
No, please, not as long as attestation is in the spec. I firmly believe that passkeys are intended to facilitate vendor lock-in and reduce the autonomy of end users.
Frankly, I do not trust any passkey implementation as much as I trust a GPG-encrypted text file.
I still don’t really understand what recovery looks like for a lost passkey… especially if I lose all of them. Not everything has a physical location where an identity can be validated, like a bank. Even my primary bank isn’t local. I’d have to drive about 6 hours to get to a branch office.
Imagine a "free porn, login here" website, when you put in your gmail address it triggers the onetime code from gmail (assuming it did that type of login) - thousands would give it up for the free porn.
Why would I put a secret code from GOOD.com into BAD.com? That's the core of the problem.
If you put a code you get from GOOD.com into BAD.com, it's like you put a password from GOOD.com into BAD.com - don't do that.
A password manager will protect me from doing the latter. There’s no way it can protect me from doing the former.
Any human can be tricked, no matter how smart they are. A bad actor just has to wait for the right moment. No amount of “don’t do that” can change that fact.
"Any human can be tricked, no matter how smart they are."
and
"A password manager will protect me from doing the latter."
Don't work together. Either everyone can be tricked or not.
It says "Everyone can be tricked" but I can't be tricked because I use a password manager.
There are many reasons why such lapses of judgements happen, even to people who don’t believe in authority. For example, the fact that any human can be tricked.
> Don't work together. Either everyone can be tricked or not.
The password manager protects me from filling my password into the wrong site.
The password manager will not protect me from BAD.com tricking me into handing them out a one-time code that GOOD.com sent me via email.
If you lose all your data and your entire life because you lost your phone, no company is responsible.
But if you get hacked they are.
So they’ve come up with a solution that can destroy your entire life, but reduces the risk of corporate liability.
But yeah, keep carrying water for the entities that won’t come up with actual user focused solutions because it may cost them 0.01% of their profits.
More like abuelita gets robbed at gunpoint and made to unlock and clear out her bank account, then has no recourse at home because her device was taken. I live in a third world country and even 2FA simply isn't viable for me due to how frequent phone robberies are. I've had to do the process once and it was a nightmare, whereas with passwords I can just log into Bitwarden wherever and I'm golden
Relying on Google/Apple is no better, with the stories of people losing access to their (Google in particular) account, and not being able to recover or let alone even reach a human at Google to begin with.
Why not have a public service for this, instead of relying on big tech that can just revoke your account for any number of ToS "violations" without recourse? The solution for "normies" should not be rely on and trust Google with your entire digital identity.
State involvement may be better used in policing, too. Public repositories of leaked passwords (without usernames, of course) would do wonders, for example
Google frequently warns me that one of my passwords has compromised but I don't really care for those sites.
The State is always more difficult and dangerous to deal with than a private company.
Ridiculous.
Google can ban me (really just one specific digital instance of me) from their services. The government can throw me in jail, take all my property, fine me whatever amount they want, etc.
I haven't used a phone 2fa forever, but it was a much better system than this "email me a code" BS.
But you're right, it's not perfect but has gotten better. Just in time to be of no use thanks to email BS.
What's 2fa token? Is that an AI thing? AI uses tokens. Or a crypto thing? Do you need one of them "nonfungible" tokens? And what's an authenticator? I have MS authenticator for work, but it uses 2 digit numbers, are those tokens?
They exist so if someone watches over your shoulder while typing your password, they don't gain access to anything.
Please stop right there. I want a password manager that I fully control, and lives on my own infrastructure (including sync between devices). Not reliance on someone else's cloud.
And if I lose my phone, I only need to do the recovery flow with the printed codes for one account, rather than for all of my accounts.
Grandma, and Uncle Rob, and your cousins, and anyone else you have a long standing relationship with, can use your VaultWarden instance if you let them.
But! You now get to maintain uptime (Rob travels and is frequently awake at 3am your time) and make sure that the backups are working... and remember that their access to their bank accounts is now in your hands, so be responsible. Have a second site and teach your niece how to sysadmin.
You are describing the current status quo, without passkeys. This is already possible.
Well, except maybe for the "without recourse" part, because there are some legal and policy avenues available for dealing with this situation.
Yes, and I'm saying that part isn't accurate either for the story you're portraying with passkeys or for the status quo. That's not how account recovery flows work.
Given how common mandatory SMS 2FA is for banks, if thieves stole your unlocked phone, they have stolen your account too.
Relying on only SMS sounds like 1FA?
Good luck. For some arcane reason, Bitwarden turned on email-based 2FA for my account last night and all of a sudden I'm locked out of my account for half a day. …mostly because I have greylisting enabled on my mail server, so emails don't arrive right away, but as it so happens I also had all my hardware stolen from me last weekend. Bootstrap is a real bitch.
I think this is what Raymond Chen calls the other side of the airtight hatch.
The game is already over. The user is already convinced the BAD website is the good website. The BAD website could just ask the user for the email and password already and the user would directly provide it. The email authenticaton flow doesn’t introduce any new vulnerability and in fact, may reduce it if the user actually signs in via a link in the email.
1) BAD actor tries to create account at GOOD website posing as [email protected].
2) GOOD website requests public key from BAD.
3) BAD provides self-generated public key.
4) GOOD later asks BAD to prove that they control the private key.
5) BAD successfully proves they control the private key.
Unless you have step 3b where GOOD can independently confirm that the public key does indeed belong to oblivious. But even that is easily worked around.
passkeys use a unique keypair per account, there's no single public key that represents you.
But as DecoPerson points out, in the realm of account creation, your "verify the email address first" solution has its limits.
It is easy to conflate different aspects of trust and think they have the same solution.
I see no reason not to use password + one of multiple 2FA methods so the user can regain control.
A common experience is Chrome telling me to scan a QR code. But I know this is not a legitimate method to sign in on any service _I_ use. I also never know WHY I'm being told to "scan this QR code". I scan it, and my phone also has no idea what to do with it! The site has decided, by not finding a passkey where it expects it, that it MUST be on my phone.
That's but one example of the horrible implementation, horribly usability, and horrible guidance various sites/applications/browsers/implementations use.
Somehow this makes me think of Pascal's Wager...
You just got through describing an attack where the victim was not aware that a bad actor can trigger a bona fide password reset code at an arbitrary time. For your little table of threats, you posit that at least clicking the link goes to the bona fide web site.
But there's a separate little table of threats for the case where an attacker controls the timing of sending a fake email. I believe realtors have this problem-- an attacker hacks their email and hangs back until the closing date approaches, then sends the fake email when the realtor tells the client to expect one with the wire transfer number/etc.
1) User goes to BAD website and enter credentials
2) BAD website use GOOD website to check if credential is valid
3) Pwned
It is just MITM attack. The moment you go to BAD and enter credential (password or one time code) you are done.
"Click a link in the email" isn't much secure either for most part. You might end up following a link blindly which can lure you into revealing even more information
Passkeys aren't that great either cause almost everyone has to provide a account recovery flow which uses these same phishable methods.
The language in communication is probably the most important deterrent here, second to using signals in the flow to present more friction to the abuser. A simple check like presenting captcha like challenge to the user in case they are not authenticating from the same machine can go a long way to prevent these kind of attacks at scale
This doesn't work. The OTP only works when paired with a key on the browser that initiated the request.
Example: Go to claude.ai and click Continue with Email. Copy the link from the email and open it in a new browser.
> However, if some popular email service suddenly decides your login emails or the login link within should be blocked, then suddenly many of your users cannot login.
This might be the only case against emailed OTPs but I don't think there is enough data to show it actually has merit.
I don't know, some would say taking an attack from trivial to virtually impossible is a bit more than a "tiny bit".
Most of the time, re: granny, women are targeted a much greater amount because of supposed weakness and vulnerability (report 2/3, victim 2/3), yet males send much larger amounts of money. ($112 vs $205) [2] Too be fair though, old people do tend to lose more with scams. Granny would probably lose $300 on average vs $113 for a 18-24. Conflicting numbers on the money #'s though, so some of that depends on which survey you ask.
Old people also tend to write each other a lot of cautionary warning stories such as the AARP article on Stan Lee's swindling in old age (security guard, "senior adviser", "protector", and daughter). [3]
Old people get a bunch of grief, yet old people are actually less likely to fall for the scams.
Also, if she's a retiree in Miami Beach, more likely to be targeted (Adak, AK; Deepwater, NJ; then Miami Beach, FL are the worst for scams.)
[1] https://www.pewresearch.org/internet/2025/07/31/online-scams...
[2] https://bbbmarketplacetrust.org/wp-content/uploads/2025/02/N...
[3] https://www.aarp.org/entertainment/celebrities/stan-lee-elde...
And there is a significant benefit of not needing to worry about weak or repeated passwords, password leaks etc.
Overall that pattern feels significantly better to me than a normal password system, and MUCH better than the "we'll send you six digits to copy and paste" solution.
- The scammer initiates a login attempt.
- The user receives a text message with a 6-digit code and might get confused.
- The user receives a phone call from the fraudster.
- The fraudster pretends to be a representative from the software platform, convincing the user there's an issue.
- At this point, another fake text message is sent, with a link to a convincing-looking platform.
- The user enters the 6-digit verification code they just saw on this fake platform.
- The scammer logs in successfully.
1) User goes to BAD website and signs up.
2) BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.”
3) BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email.
4) GOOD sends a one-time login code email to the user’s email address.
5) The user is very likely to trust this email, because it’s from GOOD, and why would GOOD send it if it’s not a proper login?
6) User enters code into BAD’s website.
7) BAD uses code to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.
This is why “email me a one-time code” is one of the worst authentication flows for phishing. It’s just so hard to stop users from making this mistake.
“Click a link in the email” is a tiny bit better because it takes the user straight to the GOOD website, and passing that link to BAD is more tedious and therefore more suspicious. However, if some popular email service suddenly decides your login emails or the login link within should be blocked, then suddenly many of your users cannot login.
Passkeys is the way to go. Password manager support for passkeys is getting really good. And I assure you, all passkeys being lost when a user loses their phone is far, far better than what’s been happening with passwords. I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.