Emailing a one-time code is worse than passwords
blog.danielh.cc
blog.danielh.cc
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 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.
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 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.
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 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
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
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.
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 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.
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
On my Windows laptop that is Windows Hello PIN, not sure about other OSs. And it can be disabled.
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.
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.
Bitwarden the password manager includes a full passkey implementation, which doesn't involve any MFA.
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.
Passkeys is an interface between your password manager and a website without all the fluff with filling or copy-pasting passwords.
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
- 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.
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 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.
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.
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.
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.
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.
Btw this predates passkeys which should perhaps be the way to go from now on.
> 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.
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.
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.
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.
- 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.
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.
- 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.
And how do you access your password manager when your computer is locked ?
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.
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 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.
passkeys use a unique keypair per account, there's no single public key that represents you.
They’re too opaque for my taste and I don’t like them.
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.
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.
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.
Now replace email a with text message sent from a short-code.
That's what phishing is predicated on, and it seems to be successful enough.
Then the banks wanted you to use the dongle to verify yourself on phone and it all went downhill from there.
Nearly every website tries to offer Google or Microsoft based sign in, "sign in partners" are commonplace.
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.
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.
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.
"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
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.
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...
> 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?
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.
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.
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.
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.
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.
I see no reason not to use password + one of multiple 2FA methods so the user can regain control.
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 don't know, some would say taking an attack from trivial to virtually impossible is a bit more than a "tiny bit".
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.
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.
Edit: See first reply, this is not a mitigation at all!
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?
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.
You can enable it on account.microsoft.com > Account Info > Sign-in preferences > Add email > Add Alias and make it primary. Then click Change Sign-in Preferences, and only enable the alias.
I guess the fix for this would be exponential backoff on failed attempts instead of a static quota of 4 a day?
Adding 2FA was the solution
I couldn't find the method they were using in the first place, because for me it always asks for the password and then just logs me in (where were they finding this 6-digit email login option?!), but this apparently blocked that mechanism completely because I haven't seen another sign-in attempt from that moment onwards. The 2FA code is simply stored in the password manager, same as my password. I just wanted them to stop guessing that stupid 6-DIGIT (not even letters!) "password" that Microsoft assigns to the account automatically...
Did I click “Yes” to the attack the fifth time, or was the sixth the attack? Or was it just a “hiccup” in the system?
Do I cancel the migration job and start from the beginning or roll the dice?
It’s beyond idiotic asking a Yes/No question with zero context, but that was the default MFA setup for a few hundred million Microsoft 365 and Azure users for years.
“Peck at this button like a trained parrot! Do it! Now you are ‘secure’ according to our third party audit and we are no longer responsible for your inevitable hack!”
Cheapest VPS is $5/month, residential proxies are $3/1Gb, which equals ~$200 / 5 years.
$3 per hacked account — is it good unit economy?
Using a modern password manager, like 1password, is _easier_, safer, and faster than the stupid email-token flow. it takes a little bit of work and attention at first to setup across a couple devices, and verify it works.... but its really about the same amount of effort as keeping track of a set of keys for your house, car, and maybe a workplace.
If you make a copy of a door key when you move into a new place, you test the key before assuming it works. Same thing with a password manager. Save a password on your phone, test it on a different device, and verify the magic sync works. Same as a key copier or some new locks a locksmith may install.
Humans can do this. You don't need to understand crypto or 2fa, but you can click 'create new password' and let the app save some insanely secure password for a new site. Same with a passkey, assuming you don't save to your builtin device storage that has some horrible, hidden user interface around backing that up for when your phone dies.
And the irony is the old flow just works better! You let the password manager do the autofill, and it takes a second or two, assuming their is an email _and_ a password input. Passkeys can be even faster.
I'm as frustrated about this as you are, but there is a large class of people who will not or can not understand and implement the password-manager workflow.
Of the people I know who are not in a tech career i'd say about 80% have nothing but contempt and ignorant fatalism toward security. The only success I've had is getting one older relative to start writing account credentials down in a little paper notebook and making sure there are numbers and letters in the passwords.
LastPass got hacked a few years ago and the few passwords my wife had on it were pwned immediately. These cloud companies lost my trust after that.
I'd only trust offline password managers, eg KeePass. Never let me down yet.
I don't know the general situation, but, at least in our small town, people would go to the phone service shop just for account setup and recovery, since it's just too complicated. Password managers and passkeys don't make things simpler for them either –– I've never successfully conveyed the idea of a password manager to a non-tech person; the passkey is somehow even harder to explain. From my perspective it's both the mental model and the extra, convoluted UX that's very hard to grasp for them.
Until one day we come up with something intuitive for general audience, passwords and the "worse" one-time code will likely continue to be prominent for their simplicity.
I've got a little generic login tool that bits I write myself use for login, using this method, but it is not for anything sensitive or otherwise important (I just want to identify the user, myself or a friend, so correct preferences and other saved information can be applied to the right person, and the information is not easily scraped) - I call it ICGAFAS, the “I Couldn't Give A Factor” Auth System to make it obvious how properly secure it isn't trying to be!
Another issue that email based “authentication” like this (though one for the site/app admins more than the end user) has is the standard set of deliverability issues inherent with modern handling of SMTP mail. You end up having to use a 3rd party relay service to reduce the amount of time you spend fighting blocklists as your source address gets incorrectly ignored as a potential spam source.
Why is NOONE talking about this? This is exactly why 2FA is less secure than password authentication, because with a password authentication, the attacker actually has to be able to capture the password in some way, whereas with 2FA, effectively anyone anywhere with the skills akin to the most junior private investigator, has the capability and tools to take over anyone's account "protected" by 2FA.
Yet we're still being told that 2FA is mandatory because security is important, and that somehow 2FA is still more secure.
Was about to post just this. This is the flow they use for account recovery so it's the weakest link in the chain anyway.
Nevermind. that pretty much all services treat the second factor as more secure than my 20 character random password saved in a local password safe. And those second factors are, lets see, plain text over SMS, plain text over the internet to an email address, etc, etc, etc.
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.
> An attacker can simply send your email address to a legitimate service, and prompt for a 6-digit code. You can't know for sure if the code is supposed to be entered in the right place.
- You are in front of the attacker site that looks like a legitimate site where you have an account (you arrived there in any way: Whatsapp link, SMS, email, whatever). Probably the address bar of your browser shows something like microsoft.minecraft-softwareupdate.com or something alike, but the random user can't tell it's fake. The page asks you to login (in order to steal your account).
- You enter the email address to login. They enter your email address in the legitimate site where you actually have an account.
- Legitimate site (for example Microsoft) sends you an email with a six digit code, you read the code, it looks legit (it is legit) and you enter it in the attacker site. They can now login with your account.
I'm in the rental market right now, and Zillow not only has a log-in for the app, but to read messages in your inbox, you have to MFA again each time, and the time-out period is about an hour.
We're being annoyed to death.
This is madness.
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 what you mean is that you have no online accounts then you are a few steps ahead of me. I will get there eventually but have some things to take care of first. Congrats on disconnecting from the internet though. I assume this site is your last holdout? I am envious if so. This site will also be my last online presence.
Consider this scenarioUser initiates login on your site.
1. You generate a code_verifier (random) and a code_challenge = SHA256(code_verifier) and store the code_verifier in the browser session (e.g., local/session storage, secure cookie, etc.).
2. You send the code_challenge to the server along with the email address.
3. Server sends the email with a login code to the user, recording the challenge (associated with the email).
4. User receives the email and enters the code on the same device/session.
Client sends the code + code_verifier to the server. Server verifies: Code is correct. SHA256(code_verifier) == stored code_challenge.
The end result is that The code cannot be used from another device or browser unless that device/browser initiated the flow and has the code_verifier.
A combination of the above and a login link might help. But ultimately, the attacker will be relying on the gullibility of the user. The user will have to not check the urls
Assuming the bot knows to send a code_challenge and send the code_verifier together with the verification code
But then again, GOOD can just also ensure that their otp can only be completed from the GOOD domain/origin. That would shore things up at least.
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.
It's about email as single factor auth, which has become very trendy of late. You just enter your email address, no password, and the email you a code. Access to your email is the only authentication.
It’s about single factor, password logins, using a one-time-token
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.
An attacker can register a domain like office375.com, clone Microsoft's login page, and relay user input to the real site. This works even with various forms of MFA, because the victim willingly enters both their credentials and second factor into a fake site. Push-based MFA is starting to show IP and location data, but a non-technical user likely won’t notice or understand the warning and a sophisticated attacker will just use a VPN matching the users' location anyways.
Passkeys solve this problem through origin enforcement. Your browser will not let you use a passkey for an origin that the passkey was not created for. If they did, you could relay those challenges as well (still better than user + pass as the challenges are useless after first use).
I appreciate most people log in and stay logged in but I frequently switch Spotify accounts and I use passwords to log in, instead of letting me choose password or a 6 digit code, every time I try and change account a needless 6 digit code is generated and sent to a shared inbox, a huge waste of resources and storage. In addition to being a security concern as flagged throughout this thread.
Try multi-account containers so no need to log out? (Or Island on Android?)
(I do agree with you about backups being essential, but my conclusion was "the idea is fundamentally flawed," rather than "it's one tweak away from greatness.")
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.
What's missing is a standardized format for the export.
This is not good for the user.
With email pasting the number into a random website is the expected flow and there is basically no protection (some phones have basic protections for SMS auth but even this only works if you are signing in on the same device).
With a username and password field, these are automatically correctly filled by Safari.
With sites that only offer an email field, I have to manually fill it.
(Note that I tend to use different emails for different sites; if you only ever use one email this might not be a problem).
It's "terrible" because the author can describe exactly one phishing vector?..
Have you ever tried resetting a password before? Passwords have a similar phishing vector, plus many other problems that magic links and one-time login codes don't have.
If six-digit login codes are less secure than passwords, the reasons why are certainly not found in this article.
Suggestions welcome if anyone has them.
If anyone would be interested I could write it up? I was surprised what a nice user flow it is and how easy it was to achieve.
As for the method itself.. IMO they're certainly phishable, but I don't think they're any more phishable than a typical username/password prompt.
> An attacker can simply send your email address to a legitimate service, and prompt for a 6-digit code. You can't know for sure if the code is supposed to be entered in the right place.
An attacker can also simply present a login prompt, say a Google-looking one, and a user will just enter their credentials.
This is why phishing-resistant authentication is the one true path forward.
If they actually are passwords, yes, my password manager is a better UX than having to fetch my phone, open SMS, wait for the SMS, like good grief it's all so slow.
(In the 2FA form, I'd prefer TOTP over SMS-OTP, but the difference is less there.)
Email magic links are more phishing resistant - the email contains a link that authenticates the device where the link was clicked. To replicate the same attack, the user would have to send the entire link to the attacker, which is hopefully harder to socially engineer.
But magic links are annoying when I want to sign in from my desktop computer that doesn't have access to my email. In that case OTP is more convenient, since I can just read the code from my phone.
I think passkeys are a great option. I use a password manager for passkeys, but most people will use platform-provided keys that are stuck in one ecosystem (Google/Apple/MS). You probably need a way to register a new device, which brings you back again to email OTP or magic link (even if only as an account recovery option).
Passkeys would be so much easier, convenient and so much more secure. I really don't understand why they go for this.
Roughly the same security for password-login with email recovery. The only difference is that this makes the attack surface larger because the user is frequently using email.
The only secure login is through 1. a hardware device and 2. a solution where both the user/service are "married" and can challenge each other during the login process. This way, your certificate of authentication will also check that the site you are connecting to is who it says it is.
I’m pretty sure we can prevent this by issuing some kind of proof of agreement (with sender and recipient info) thru email services. Joining a service becomes submitting a proof to the service, and any attempt to contact the user from the service side must be sealed with the proof. Mix in some signing and HMAC this should be doable. I mean, IF we really want to extend the email standard.
How does this scheme stop you from putting a legitimate code from a legitimate sender into an illegitimate website?
https://support.microsoft.com/en-us/account-billing/how-to-g...
Just like sending large files over the internet.
1. authentication via password: accounts stolen by criminals and then inaccessible to the user.
2. authentication via passkey: accounts lost by users because passkeys have friction, to say the least, when devices are lost/stolen/transferred.
It seems that big providers would much rather scenario 2.
1. Mobile phone numbers are not secure. SIM jacking is a thing, and a 6 digit code is not impossible to guess (it's only 1 in a million).
2. Sending codes/links via email is problematic as described by the article.
3. Inconsistent "best practices" confuse users, and frustrate them.
If i use a personal email then I can’t access it on corporate machines and vice versa.
Theres so much friction in the process it’s not worth maintaining the service.
They do provide Google sign-in, but I've had issues with Google sign-in during traveling too often to consider it a legitimate option.
It's also terrible UX. Emails don't always arrive right away. (Especially if you've enabled greylisting.)
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!
The "Simply" music apps use a four digit code, sent by mail. And that never changes.
Easy account sharing! It is a feature!
So I asked my friend Miss Chatty [1] about it. Hopefully this will help anyone who is as confused as I was.
https://chatgpt.com/share/68947f35-0a10-8012-9ae9-adadc3df8b...
[1] Siri and Alexa get to have cool names, so why can't ChatGPT?
A better workflow is to send the user a link where they can set their initial password themselves.
Here is what I do when the user logs in and email verification is needed:
1. Generate a UUID on the server.
2. Save the UUID on the client using the Set-Cookie response header.
- The cookie value is symmetrically encrypted and authenticated via HMAC or AES-GCM by the server before it is set, such that it can only be decrypted by the server, and only if the cookie value has not been tampered with. This is very easy to do in hapi.js and any other framework that has encrypted cookies.
- Use all the tricks to safeguard the cookie from being intercepted and cloned. For example, use a name with the __Host- prefix and these attributes: Secure; HttpOnly; SameSite=Lax;
3. The server sends an email to the user with a link like https://site.com/verify?code=1234, where 1234 is the UUID.
4. The user clicks the link and has their email verified.
- When the link is clicked, the browser sends the Cookie header automatically, the server decrypts it and compares it to the UUID in the URL and if that succeeds, the email has been verified. Again, this is very easy in hapi.js, as it handles the decryption step.
- Including the UUID in the magic link signals that there is _supposed_ to be a cookie present, so if the cookie is missing or it doesn't match, we can alert the user. It also proves knowledge of the email, since only the email has access to the UUID in unencrypted form.
5. The server unsets the cookie, by responding with a Set-Cookie header that marks it as expired.
6. The server begins a session and logs the user in, either on the page that was opened via the link or the original page that triggered the verification flow (whichever you think is less likely to be an attacker, probably the former).
Note that there are some tradeoffs here. The upside is that the user doesn't need to remember or type anything, making it harder to make mistakes or be taken advantage of. The downside is that the friction of having to use the same device for email and login may be a problem in some situations. Also, some email software may open a different browser when the link is clicked, which will cause the cookie to be missing. I handle this by detecting the missing cookie and showing a message suggesting the user may need to copy-paste the link to their already open browser, which will work even if they open a new tab to do it (except for incognito mode, where some browsers use a per-tab cookie jar).
Lastly, no cookie is 100% safe from being stolen and cloned. For example, a social engineering attack could involve tricking the user into sharing their link and Set-Cookie header. But we've made it much more difficult. They need two pieces of information, each of which generally can't be intercepted, or used even if intercepted, by intermediary sites.
1. There's very low consistency in implementation, so while I understand the problems passkeys solve, it seems like every vendor has chosen different subproblems of the problem space to actually implement. Does it replace your password? Does it replace MFA? Can I store multiple passkeys? Can I turn off other forms of MFA? Do I still need to provide my email address when I sign in (Github actually says No to this)?
2. The experience of passkeys was supposed to be easier and more secure than passwords for users who struggle to select good passwords, but all I've observed is: Laypeople whose passwords have never been compromised, in 20 years of computing, now deeply struggling to authenticate with services. Syncing passwords or passkeys between devices is something none of these people in my life have figured out. I still know two people in their late 20s who use a text file on their computer and Evernote to manage their passwords. What is their solution for passkeys? They don't know. They're definitely using them though. The average situation I've seen is: "What the heck is this how do I do this I guess I'll just click save passkey on this iOS prompt" and then they can never get back into that service. The QR code experience for authenticating on desktop using mobile barely works on every Windows machine I've seen.
3. There is still extremely low support among password managers for exporting passkeys. No password managers I've interacted with can do it. Instead its to my eyes become another user-hostile business decision; why should we prioritize a feature that enables our users to leave my product? "Oh FIDO has standardized the import/export system its coming" Yeah we've also standardized IPv6. Standards aren't useful until they're used. "Just create new passkeys instead of exporting" as someone who has recently tried to migrate from 1Password to custom-hosted Bit/Vaultwarden: This is the reason why I gave up. By the way, neither of these products support exporting passkeys.
It might end up being like USB-C where its horrible for the first ten years, but slowly things start getting better and the vision becomes clear. But I think if that's the case: We The Industry can't be pulling an Jony Ive Apple 2016 Macbook Pro and telling users "you have to use these things and you have no other option [1]". Apple learned that lesson. I'm also reasonably happy with how Apple has implemented Passkeys (putting aside all the lockin natural to using Apple products, at least its expected with them). But no one else learned that lesson from them.
[1] https://www.cnet.com/tech/your-microsoft-passwords-will-vani...
1. You go to evil.example.com, which uses this flow.
2. It prompts you to enter your email. You do so, and you receive a code.
3. You enter the code at evil.example.com.
4. But actually what the evil backend did was automated a login attempt to, like, Shopify or some other site that also uses this pattern. You entered their code on evil.example.com. Now the evil backend has authenticated to Shopify or whatever as you.
* Electronic mail (the technology)
* An email message
* An email address
* An email inbox
In this example they mean email address.
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.
like similar to if you get a "your login" yes/no prompt on a authentication app, but a bit less easy to social engineer but a in turn also suspect to bruteforce attacks (similar to how TOTP is suspect to it)
through on the other hand
- some stuff has so low need of security that it's fine (like configuration site for email news letters or similar where you have to have a mail only based unlock)
- if someone has your email they can do a password reset
- if you replace email code with a login link you some cross device hurdles but fix some of of social enginering vectors (i.e. it's like a password reset on every login)
- you still can combine it with 2FA which if combined with link instead of pin is basically the password reset flow => should be reasonable secure
=> eitherway that login was designed for very low security use cases where you also wouldn't ever bother with 2FA as losing the account doesn't matter, IMHO don't use it for something else :smh: