Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

111–120 of 816 posts

Re: Emailing a one-time code is worse than passwords

#111
post #74

Earlier quoted context omitted.

Do you have some examples where people actually require attestation in 3rd party facing systems? Or is this purely "But in theory..." and you've dismissed all the very real problems with the alternatives because you're scared of a theoretical problem ? 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.

They're not going to start requiring them until they've phased out non-passkey login. But at that point it will be too late.

I don't know why people don't see this coming: very obviously once Passkeys are everywhere, it'll become "we're requiring attestation from approved device bootloaders/enclaves" and that'll be your vendor lock in where it'll be just difficult enough that unless you stick with the same providers phone, you might lose all your passkeys.

Re: Emailing a one-time code is worse than passwords

#112
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.

Re: Emailing a one-time code is worse than passwords

#113

I'm having difficulty understanding what it means for an attacker to "send your email to a legitimate service"...

I think this means: 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 Shopif…

The site is comparing this method to plain username + password though. Doesn't that miss the obvious point that evil.example.com could do the exact same thing with the username + password method, except it's even easier to phish because they just get your username + password directly (when you type them in) and then an attacker can log in as you via a real browser?

Re: Emailing a one-time code is worse than passwords

#114
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.

Re: Emailing a one-time code is worse than passwords

#115

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-pas…

> 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.

Re: Emailing a one-time code is worse than passwords

#116
post #22

The attack pattern is: 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…

It sounds good, unless granny needs to visit Google or Microsoft to get a new password after losing her phone. Then what??

The scary part is not about losing her phone. It's about having to keep the old, no-longer-secure Android phone alive just for passkeys after getting a shiny (and secure) new iPhone.

Re: Emailing a one-time code is worse than passwords

#117

Earlier quoted context omitted.

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.

That's still not perfect though! Most leaked passwords online come initially from leaked hashes, which bad actors use tools like hashcat to crack. If your user has a password like "password123" and the hash gets out, then the password is effectively out too, since people can easily lookup the hash of previous cracked passwords like "password123".

No. This is why salts[0] are used.

[0] https://en.wikipedia.org/wiki/Salt_(cryptography)

Re: Emailing a one-time code is worse than passwords

#118

The attack pattern is: 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…

> I’d rather granny needs to visit the bank to get access to her account again

Visiting the bank is fine. But who do you visit to recover your Gmail password?

Re: Emailing a one-time code is worse than passwords

#119

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!

Such long passwords are silly, they will be effectively truncated by the key length of the underlying cryptography.

Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.

Re: Emailing a one-time code is worse than passwords

#120

Earlier quoted context omitted.

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.

That's still not perfect though! Most leaked passwords online come initially from leaked hashes, which bad actors use tools like hashcat to crack. If your user has a password like "password123" and the hash gets out, then the password is effectively out too, since people can easily lookup the hash of previous cracked passwords like "password123".

Salting already fixed this decades ago, and most modern password libraries will automatically generate and verify against a hash like $salt$saltedhash if you use them instead of rolling your own.
Post reply on HN