Erm... Passkeys _are_ backupable/syncable WebAuthn keys. You can get the clear-text Passkey private keys by just looking into your storage (Keychain on iOS).
What's missing is a standardized format for the export.
Same. Sacrificing security by selling superficial convenience and limited security advantages for crucial inconveniences.
Perhaps there ought to be a well-known, "ACME" password-changing API such that a password manager could hypothetically change every password for every service contained in an automated fashion.
It means that you go to foo.com and enter your e-mail to sign up. But foo.com routes that request and to bank.com, hoping you have an account there.
bank.com sends you verification email, which you expect from foo.com as part of the sign-up verification process. For some bat shit crazy reason, you ignore that the email came from bank.com and not foo.com and you type in the secret code from the email into the foo.com to complete the sign up process.
And bam! the foo.com got into your bank account.
A complete nonsense but because it works in 0.000000000000001% of the time for some crazy niche cases in the real world, let's talk about it.
Wholeheartedly agree, however The Changelog Podcast helped shift my perspective on this. It's really about not having the responsibility of storing and maintaining passwords.
You should never store passwords anyways. You store hashes. I don’t see the issue. If you don’t trust yourself to keep a hash, maybe don’t store user information at all.
So if they don't want to store your passwords because they do not want the responsibility of keeping it safe, should you trust your credit card and other personal information with them?
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.
Links are more worse than otp but both can easily be secure if users check domain which users never do so links and otp are terrible. Long live passkeys.
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). The biggest problem are attestations, which let services block users who use tools that give them more freedom. Passkeys, or more generally challenge-response protocols, could easily have been an amazing replacement for passwords and a win-win for everyone. Unfortunately, the reality of how they've been designed is that they will mainly serve to further cement the primacy of BigTech and take away user freedom.
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.
If we are talking about real time phishing then sending a code to the email is as secure as a 2FA authentication with password and Google Authenticator code.
I guess this flow is even worse for authenticators like Duo or even Apple’s own iCloud logins with 2fa. You log on to a phishing site mimicking the real one, and your phone asks if it is you trying to log in. Yes of course it’s you logging in, but you don’t realize you’re logging in bad guys by proxy.
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.
Passkeys are still a shared secret, aren't they? Asymmetric cryptography would have been amazing. Barring that I would actually recommend Oauth or something like it, to limit the number of parties who manage shared secrets to a smaller set of actors who have more experience doing so.
I don’t like passkeys. Before my process to login was:
- 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
Passkeys would be great if they actually made anything simpler on a computer. They work fine on the phone but that’s not where I spend most of my time.
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.
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.
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.
Would it be a viable and simple solution to only enter 6-digit codes into the specific website that requested it?
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?
I'm not sure what kind of websites are vulnerable to these attacks, but websites that have double authentication seem pretty safe to me. And if you forgot your password, then you receive an e-mail to change it with a secure link.
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 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.
"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.
> 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.
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.
> 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.
I am waiting for the era when using passkeys is not depending from some big tech company.
But you could replace #2 with "Enter your password from GOOD, as they are our sign-in partner". I'm not in favor of emailing 6 digit codes either, but your scenario presupposes that users will be willing to trust that two services have intermingled their auth, and in that case their password can be wrangled from them too.
I like capability URLs. I know an URL isn't a secret, but it works in practice and it works well.
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.
> Passkeys is the way to go. Password manager support for passkeys is getting really good.
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.
I hate passkeys because even as a savvy user, I don’t know what to do with them. Do they replace my password? Do I need to generate one passkey per account and per device? How do I login on a new device? Are password managers still relevant with passkeys?
They’re too opaque for my taste and I don’t like them.
If attacker would fool me at one website he will get that one account (possibly forever) and that's it. If it is a bank connected account, I can intervene and change email/account by writing a physical request to the bank for example, call the bank, do something. And likely it will be only a single bank account. But it may be even some unrelated account. Maybe it will be my Amazon account and all the attacker gets is some ebooks. Or Steam account. Or some email without important links. Etc.
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.
> 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.
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.
Good points but dont underestimate "granny needs to visit the bank to get access to her account again" as a problem.
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.
Passkeys will be the way to go if we get them to remove the "attestation object" field from the protocol. Until then there's no way for Jimbob to tell the difference between:
> 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).
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.
Passkeys are cloneable though and a clear step back compared to Yubikeys for FIDO2/webauthn.
Heck, we even used to have a counter where the user could know if one of its key had been duplicated. I tested this years ago and it worked. That's gone now.
For people with strong interests to introduce backdoors worked very hard to lower the security we had: it was too good. The people behind this are going to pretend they lowered security in the name of convenience but to me that's just the excuse: the goal was to lower security and they'll say "we need cloneable passkeys otherwise it's just too inconvenient". xxxINT.
Now I'll agree: for regular people passkeys are way better than PIN code or whatever. But if you're a target like a journalist reporting on crooked politicians or a whistleblower exposing frauds, don't go think your passkeys cannot be cloned and used to access your various accounts. Passkeys can be cloned by design. And it's all in totally opaque part of the hardware stack under the control of a few very state-friendly corporations.
And those pushing passkeys as the next best thing since sliced bread happen to very often also be the one always turning a blind eye to their states' wrongdoings.
So yup, passkeys are good but, no, they didn't lower the security for no reason. So don't rely on passkeys if you're the next Snowden.
And certainly don't go to listen to state-apologists explaining that states wouldn't do such things as lowering security standards in order to make sure they've got their shiny backdoors.
Isn’t clicking on a link in an email also problematic? It gets users in the habit of trusting links in emails. There is a history of those being used in bad ways as well.
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.
Mobile phone App/Passkey authentication is just a way to pass the responsibility down to users. Losing a phone today is not just losing the passkey, there are "login with QR-code" schemes too, which do not need a password at all. It is a bad trend to pass all security onto the physical phone.
If the target was not actively trying to log into GOOD at that exact moment, why would they treat this as anything other than one of a phishing attempt or spam?
I haven't been able to get into my Oracle (free) account for 2 years because I lost 2fa... Unless I start needing to pay them for something, they'll probably never answer my emails. There are consequences for losing your phone when using alternative authentication methods (be careful).
>"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."
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
I feel like this is a really strong justification for duress passwords. Register a duress password with your phone or bank account, and if you ever enter it, that system will take whatever actions you want - call the police with your location, display a fake balance of a few hundred dollars, switch to a fake email account, hide your crypto wallet app, whatever.
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.
Please help me understand the passkey flow that solves this problem.
1) BAD actor tries to create account at GOOD website posing as oblivious@example.com.
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.
What about the 99 other places granny needs to regain access to after the much more common broke or lost phone many of which doesn't have a meaningful amount of customer service.
I see no reason not to use password + one of multiple 2FA methods so the user can regain control.
I work on a product that emails administrators with a list of actions they can take related to certain authorization requests. We got feedback from a customer that all requests were simultaneously approved then denied. It turns out their Microsoft provided email server follows all links and runs all javascript before showing it to the user
Passkeys are a usability nightmare. No two experiences are ever the same. I have passkeys saved in 1Password and in Apple Passwords. I have a YubiKey. I have Duo on my work computer.
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.
> “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.
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.
I suppose the GOOD site should say "do not enter this code on any other sites, we are NOT a login partner for any other sites" but a lot of people would probably not read that. Still, it would help. The very tricky thing about this scam is that it gets people to react to an email that they are expecting. Which means they will not be as guarded as if they got an email out of the blue.
I am afraid that this flaw is present for almost all phishable methods (SMS, TOTP, email OTP, App Push) to certain extent (except passkeys, mtls)
"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
Re: Granny - Pew Research about Online Scams, granny is far less likely to lose her account (15%) than an 18-29 year old (26%). If she's upper income and white even less likely. Similar trends with falling for large numbers of scams. People who've had 3+, granny (19%), 18-26 year olds (24%). [1] The survey notably has the same perception results. Society views the youth as mostly immune from scams (believe only 22%), yet fall victim to them (26%), while worrying about old people (believe 84% fall for them), who actually don't fall victim that often (15%).
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.)
Good explanation!
The GOOD's email should contains "Never give this code to others" and the user should know this clearly. I like phone and email OPT, it's easy to login.
I think the "click a link in the email" solution is more than a "tiny" bit better isn't it? It almost completely solves the attack pattern you laid out. Passing the whole link to BAD is not only more tedious but totally ridiculous. That is not the kind of thing that even totally naive users would do.
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.
Or I could keep using passwords in my password manager, where I DON’T lose all my passwords if I lose my phone? Passkeys just seem to solve no real problems and create a black box dependency. Everything I’ve seen about them just makes no damn sense.
Aren't your passkeys stored with your password manager? As long as you have web access to your password manager, why would losing your phone be an issue? I am not a passkey users as I find them pretty confusing...
The scene you described helped me quickly grasp the whole situation! I'd like to add a new example. In your example, the most dangerous part is "the user being convinced to visit the BAD website." Here's my example:
- 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.
Still seems far, far more likely that the average user will have their account stolen via password theft/reuse than the more complicated scheme the author is describing. Links instead of codes also fixes the issue.
So there are two complaints about this authn scheme that I'm seeing in this thread:
1. It's pretty phishable. I think this is mostly solved, or at least greatly mitigated, by using a Slack-style magic sign-in link instead of a code that you have the user manually enter into the trusted UI. A phisher would have to get the user to copy-paste the URL from the email into their UI, instead of clicking the link or copy-pasting it into the address bar. That's an unusual enough action that most users probably won't default to doing it (and you could improve this by not showing the URL in HTML email, instead having users click an image, but that might cause usability problems). It's not quite fully unphishable, but it seems about as close as you can get without completely hiding the authentication secret from the user, which is what passkeys, Yubikeys, etc., do. I'd love to see the future where passkeys are the only way to log into most websites, but I think websites are reluctant to go there as long as the ecosystem is relatively immature.
2. It's not true multi-factor authn because an attacker only needs to compromise one thing (your inbox) to hijack your account. I have two objections to this argument:
a. This is already the case as long as you have an email-based password reset flow, which most consumer-facing websites are unwilling to go without. (Password reset emails are a bit less vulnerable to phishing because a user who didn't request one is more likely to be suspicious when one shows up in their inbox, but see point 1.)
b. True multi-factor authn for ordinary consumer websites never really worked, and especially doesn't work in the age of password managers. As long as those exist, anyone who possesses and is logged into the user's phone or laptop (the usual prerequisites for a possession-based second factor) can also get their password. Most websites should not be in the business of trying to use knowledge-based authentication on their users, because they can't know whether the secret really came from the user's memory or was instead stored somewhere, the latter case is far more common in practice, and only in the former case is it truly knowledge-based. Websites should instead authenticate only the device, and delegate to the device's own authentication system (which includes physical possession and likely also a lock secret and/or biometric) the task of authenticating the user in a secure multi-factor way.
* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.
* Some people don’t have their email on the device they want to log in on.
Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)
> think this is mostly solved, or at least greatly mitigated, by using a Slack-style magic sign-in link instead of a code that you have the user manually enter into the trusted UI.
Magic links are better than codes, but they don't work well for cross-device sign-in. What Nintendo does is pretty great: If I buy something on my switch, it shows me a QR code I take a picture of with my phone and complete the purchase there.
I agree it is "mostly solved" in that there are good examples out there, but this is a long way from the solution being "best practices" that users can expect the website/company to take security seriously.
> a. This is already the case as long as you have an email-based password reset flow
I hard-disagree:
If I get an email saying "Hi you are resetting your password, follow these directions to continue" and I didn't try to reset my password I will ignore that email.
If I have to type in random numbers from my email every few days, I'm probably going to do that on autopilot.
These things are not the same.
> anyone who possesses and is logged into the user's phone or laptop (the usual prerequisites for a possession-based second factor) can also get their password.
I do not know what kind of mickey-mouse devices you are using, but this is just not true on any device in my house.
Accessing the saved-password list on my computer or phone requires an authentication step, even if I am logged-in.
I also require second-authentication for mail and a most other things (like banking, facebook, chats, etc) since I do like to let my friends just "use my phone" to change something on spotify or look up an address in maps.
> Most websites should not be in the business of trying to use knowledge-based authentication on their users, because they can't know whether the secret really came from the user's memory or was instead stored somewhere
They can't know that anyway, and pretending they do puts people at risk of sophisticated attackers (who can recover the passkey) and unsophisticated incompetence on behalf of the website (who just send reset links without checking).
> Websites should instead authenticate only the device, and delegate to the device's own authentication system
I disagree: Websites have no hope of authenticating the device and are foolishly naive to try.
Some sites make this into a problem accessing their site by having an unsubscribe that doesn't account for this login method. Unsubscribing from marketing means I can no longer login
Indeed, such a bad design where instead of a simple and quick 1-shortcut login from a fishing-resistant password manager users have to waste time switching back and forth between different apps/devices
What's quite annoying is how agressive most products are into forcing this method over regular email+pw / Social Logins. Let me use my 100 chars password!
This has been driving me nuts. Ever since implementation. This method has been the biggest disappointment of login procedures and quickness. I dont want to go through, three to five steps just to login and in the meantime I forget what I came to the service for in the first place. There's gotta be a better method for security and streamlining sign in's. I should not have to do the work of security for the service and every other week I hear about the same service being hacked and millions of accounts are now affected.
Four times a day, I get an email notification that someone requested a password reset for my Microsoft account, which gives me a six-digit number to recover my account. So every day, an attacker has four shots in 1,000,000 of stealing my account by just guessing the number. They've been doing this for years.
If the attacker's doing this to thousands of accounts - which I'm sure they are - they're going to be stealing accounts for free just by guessing.
I wrote up a security report and submitted it and they said that I hadn't sufficiently mathematically demonstrated that this is a security vulnerability. So your only option is to get spammed and hope your account doesn't get stolen, I guess.
I believe (and the article should make it clear) that the article is criticizing specifically the use of the code that user must enter into a box, which invites man-in-the-middle attacks.
The article is not advocating against e-mail-driven URL-based password reset/login, whereby the user doesn't enter any code, but must follow a URL.
The six digit code can be typed into a phony box put up by a malicious web site or application, which has inserted itself between the user and the legitimate site.
The malicious site presents phony UI promoting the user to initiate a coded login. Behind the scenes, the malicious site does that by contacting the genuine site, and provoking a coded login. The user goes to their inbox and copies the code to the malicious site's UI. The site then uses it to obtain a session with the genuine site, taking over the user's account.
A SSL protected URL cannot be so easily intercepted. The user clicks on it and it goes to the domain of the genuine site.
Some days when I'm tired of receiving a new authentication code, I'm half-jokingly thinking : we're certainly must reaching a point where at least half of all SMS messages sent are authentication codes (with a small payload, for now).
A passphrase is basically like a password in the sense that I can lose it, but it's not like a password in the sense that I can actually memorise it. (Or rather, all of them)
I prefer my passwordstore workflow.
I remember two passwords, the rest is kept save for me and unlocked when I need them.
It's not perfect, but it's by far the least worse solution of them all.
178 comments
[ 3.0 ms ] story [ 133 ms ] threadWhat's missing is a standardized format for the export.
Perhaps there ought to be a well-known, "ACME" password-changing API such that a password manager could hypothetically change every password for every service contained in an automated fashion.
bank.com sends you verification email, which you expect from foo.com as part of the sign-up verification process. For some bat shit crazy reason, you ignore that the email came from bank.com and not foo.com and you type in the secret code from the email into the foo.com to complete the sign up process.
And bam! the foo.com got into your bank account.
A complete nonsense but because it works in 0.000000000000001% of the time for some crazy niche cases in the real world, let's talk about it.
* Electronic mail (the technology)
* An email message
* An email address
* An email inbox
In this example they mean email address.
This is not good for the user.
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.
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.
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:
Passkeys would be great if they actually made anything simpler on a computer. They work fine on the phone but that’s not where I spend most of my time.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.
Visiting the bank is fine. But who do you visit to recover your Gmail password?
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.
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.
And how do you access your password manager when your computer is locked ?
Edit: See first reply, this is not a mitigation at all!
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?
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 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.
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?
I am waiting for the era when using passkeys is not depending from some big tech company.
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.
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.
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.
> 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).
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 agree but...
Passkeys are cloneable though and a clear step back compared to Yubikeys for FIDO2/webauthn.
Heck, we even used to have a counter where the user could know if one of its key had been duplicated. I tested this years ago and it worked. That's gone now.
For people with strong interests to introduce backdoors worked very hard to lower the security we had: it was too good. The people behind this are going to pretend they lowered security in the name of convenience but to me that's just the excuse: the goal was to lower security and they'll say "we need cloneable passkeys otherwise it's just too inconvenient". xxxINT.
Now I'll agree: for regular people passkeys are way better than PIN code or whatever. But if you're a target like a journalist reporting on crooked politicians or a whistleblower exposing frauds, don't go think your passkeys cannot be cloned and used to access your various accounts. Passkeys can be cloned by design. And it's all in totally opaque part of the hardware stack under the control of a few very state-friendly corporations.
And those pushing passkeys as the next best thing since sliced bread happen to very often also be the one always turning a blind eye to their states' wrongdoings.
So yup, passkeys are good but, no, they didn't lower the security for no reason. So don't rely on passkeys if you're the next Snowden.
And certainly don't go to listen to state-apologists explaining that states wouldn't do such things as lowering security standards in order to make sure they've got their shiny backdoors.
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.
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.
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
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 oblivious@example.com.
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.
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
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.
While the premise is correct -- it's easy to complain but the author also provides zero recommendations on what is a better form of MFA.
Let’s be honest all forms of auth suck and have pros and cons.
The real solution is detect weird logins because users cannot be trusted. That’s why we build for them!
1. It's pretty phishable. I think this is mostly solved, or at least greatly mitigated, by using a Slack-style magic sign-in link instead of a code that you have the user manually enter into the trusted UI. A phisher would have to get the user to copy-paste the URL from the email into their UI, instead of clicking the link or copy-pasting it into the address bar. That's an unusual enough action that most users probably won't default to doing it (and you could improve this by not showing the URL in HTML email, instead having users click an image, but that might cause usability problems). It's not quite fully unphishable, but it seems about as close as you can get without completely hiding the authentication secret from the user, which is what passkeys, Yubikeys, etc., do. I'd love to see the future where passkeys are the only way to log into most websites, but I think websites are reluctant to go there as long as the ecosystem is relatively immature.
2. It's not true multi-factor authn because an attacker only needs to compromise one thing (your inbox) to hijack your account. I have two objections to this argument:
a. This is already the case as long as you have an email-based password reset flow, which most consumer-facing websites are unwilling to go without. (Password reset emails are a bit less vulnerable to phishing because a user who didn't request one is more likely to be suspicious when one shows up in their inbox, but see point 1.)
b. True multi-factor authn for ordinary consumer websites never really worked, and especially doesn't work in the age of password managers. As long as those exist, anyone who possesses and is logged into the user's phone or laptop (the usual prerequisites for a possession-based second factor) can also get their password. Most websites should not be in the business of trying to use knowledge-based authentication on their users, because they can't know whether the secret really came from the user's memory or was instead stored somewhere, the latter case is far more common in practice, and only in the former case is it truly knowledge-based. Websites should instead authenticate only the device, and delegate to the device's own authentication system (which includes physical possession and likely also a lock secret and/or biometric) the task of authenticating the user in a secure multi-factor way.
* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.
* Some people don’t have their email on the device they want to log in on.
Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)
Magic links are better than codes, but they don't work well for cross-device sign-in. What Nintendo does is pretty great: If I buy something on my switch, it shows me a QR code I take a picture of with my phone and complete the purchase there.
I agree it is "mostly solved" in that there are good examples out there, but this is a long way from the solution being "best practices" that users can expect the website/company to take security seriously.
> a. This is already the case as long as you have an email-based password reset flow
I hard-disagree:
If I get an email saying "Hi you are resetting your password, follow these directions to continue" and I didn't try to reset my password I will ignore that email.
If I have to type in random numbers from my email every few days, I'm probably going to do that on autopilot.
These things are not the same.
> anyone who possesses and is logged into the user's phone or laptop (the usual prerequisites for a possession-based second factor) can also get their password.
I do not know what kind of mickey-mouse devices you are using, but this is just not true on any device in my house.
Accessing the saved-password list on my computer or phone requires an authentication step, even if I am logged-in.
I also require second-authentication for mail and a most other things (like banking, facebook, chats, etc) since I do like to let my friends just "use my phone" to change something on spotify or look up an address in maps.
> Most websites should not be in the business of trying to use knowledge-based authentication on their users, because they can't know whether the secret really came from the user's memory or was instead stored somewhere
They can't know that anyway, and pretending they do puts people at risk of sophisticated attackers (who can recover the passkey) and unsophisticated incompetence on behalf of the website (who just send reset links without checking).
> Websites should instead authenticate only the device, and delegate to the device's own authentication system
I disagree: Websites have no hope of authenticating the device and are foolishly naive to try.
except I'm a user, not a device
>>I<< want to be authenticated, not my specific device that I'm going to switch at some point
If the attacker's doing this to thousands of accounts - which I'm sure they are - they're going to be stealing accounts for free just by guessing.
I wrote up a security report and submitted it and they said that I hadn't sufficiently mathematically demonstrated that this is a security vulnerability. So your only option is to get spammed and hope your account doesn't get stolen, I guess.
The article is not advocating against e-mail-driven URL-based password reset/login, whereby the user doesn't enter any code, but must follow a URL.
The six digit code can be typed into a phony box put up by a malicious web site or application, which has inserted itself between the user and the legitimate site.
The malicious site presents phony UI promoting the user to initiate a coded login. Behind the scenes, the malicious site does that by contacting the genuine site, and provoking a coded login. The user goes to their inbox and copies the code to the malicious site's UI. The site then uses it to obtain a session with the genuine site, taking over the user's account.
A SSL protected URL cannot be so easily intercepted. The user clicks on it and it goes to the domain of the genuine site.
A passphrase is basically like a password in the sense that I can lose it, but it's not like a password in the sense that I can actually memorise it. (Or rather, all of them)
I prefer my passwordstore workflow.
I remember two passwords, the rest is kept save for me and unlocked when I need them.
It's not perfect, but it's by far the least worse solution of them all.