Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

601–610 of 816 posts

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

#601

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…

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

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

#602

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…

Four times a day, times say 5 years = 7_300 tries. Times 10_000 accounts ≈ 73_000_000 tries. They should have access to ~70 accounts by now.

Cheapest VPS is $5/month, residential proxies are $3/1Gb, which equals ~$200 / 5 years.

$3 per hacked account — is it good unit economy?

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

#603

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…

> Passkeys is the way to go. 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 use a FIDO2 security key, I fail to see how I am locked in. Can you elaborate?

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

#604

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.

The Fido2 folks really really want things to be so secure and centralized, with so little user freedom, and they want to use attestation to do it. Here's a Fido2 member (Okta) employee saying "If keepass allows users to back up passkeys to paper, I think we'll have to allow providers to block keepass via attestation." https://github.com/keepassxreboot/keepassxc/issues/10407#iss... All because passkeys backup is deeme…

Hi, since you mentioned me, that's not what was said and putting it in quotes as if I did is really inappropriate.

I'll post the same response I replied to other on a different thread:

Wild that you (and a few others) continue to make these accusations about me in these comments (and in other venues).

1) I've been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice

2) What makes you think I have any say or control over the hundreds of millions of websites and services in the world?

3) There is no known synced passkey credential manager that attests passkeys.

tl;dr attestation does not exist in the consumer synced passkey ecosystem. Period.

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

#605
post #415

Earlier quoted context omitted.

Your style of thinking is exactly why linux never became a leader in desktop os's. Why we're still dealing with the most ridiculous tech debt and complexity in OSS tooling to date. You're obsessed with fake problems that have no bearing on real people. When grandma does indeed loose all her money because some prick phished her password away, I would love to watch you explain how that's actually better than BigTech ta…

This argument is ridiculous and purposefully inflammatory. The issue at hand is the requirement for client attestation while using passkeys. So in that light, can you describe for us the scenario in which grandma, who is undoubtedly using passkeys on an iPhone or an Android, looses all her money simply because someone, somewhere else is using a passkey without attestation? You can't, because the vendor lock-in create…

> The issue at hand is the requirement for client attestation while using passkeys.

There is no attestation in the consumer synced passkey ecosystem. Period.

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

#606

Earlier quoted context omitted.

uh no - a password manager is an open source application you can compile and install yourself if you want. Its nothing more than a small specialised database with a excel like interface. Personally I think that the argument that things are "too complicated for the average user" eventually gets gets you users that find breathing and sphincter function too complicated.

I’ve been observing this space for two decades and haven’t come across a single open-source password manager that actually works, is properly maintained, has an acceptable security track record, and comes with a similarly well-maintained browser extension that protects both my clipboard and myself from phishing.

What about Bitwarden?

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

#607

Earlier quoted context omitted.

Did people not realize they can save their 2fa token and just use that with a new authenticator? I haven't used a phone 2fa forever, but it was a much better system than this "email me a code" BS.

>> Did people not realize they can save their 2fa token and just use that with a new authenticator? What's 2fa token? Is that an AI thing? AI uses tokens. Or a crypto thing? Do you need one of them "nonfungible" tokens? And what's an authenticator? I have MS authenticator for work, but it uses 2 digit numbers, are those tokens?

Not sure if I'm missing a joke, but the 2fa token is a secret that you stick in your password manager and sync (or otherwise send) to other devices so that your 2fa is not bound to a particular device. My password manager lets me view the 2fa secret as if it were just another password.

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

#608

Earlier quoted context omitted.

rpdililon mentioned KeePass. What have you (that is, Hackbraten) found wrong with the KeePassXC offshoot of it? /me wonders if this is a "recommend me a nice open source, offline password manager" question in disguise.

I don’t remember why KeePassXC didn’t make my list last time I checked. That was years ago, so I’m going to check it out again. Thanks for the pointer. Update: One thing that stands out immediately is a confusing mess of three different projects, two of them unmaintained, which all call themselves KeePassX or KeePassXC, sometimes linking to each other’s documentation. How do I even tell I’m facing the correct KeePass…

> How do I even tell I’m facing the correct KeePass(X(C)?)? project?

Well, [0] lists a single project called KeePassXC, with [1] as its homepage. Search engines list [1] and [2] as the top results for the query KeePassXC, for whatever that's worth. [3]

> Also, if a password manager project needs to be forked over and over and over again ... then does that tell us something about how the project is governed?

No?

KeePass is Windows-only software. So, some folks decided to write KeePassX, which ran on Linux, OSX, and Windows. They got bored of that after a decade or so, called it quits, and one of the preexisting forks [4] became the widely-used one.

> how can a holder of the keys to the kingdom possibly go MIA on three different occasions in basically the same project?

In addition to the history I wrote above, you are aware that KeePass is still receiving stable releases? According to [5], it looks like 2.59 was released just last month.

EDIT: Actually, where are you getting this "confusing mess of three different projects" from? When I search for "keepass", I get the official home pages for KeePass and KeePassXC as the top two results, the Wikipedia page, and then the Keepass project's SourceForge downloads page. When I search for "keepassx", I get the official homepages for KeePassX and KeePassXC, the wikipedia page, the KeePassXC Github repo, and an unofficial SourceForge project page for KeePassX.

[0] https://keepass.info/download.html>

[1] https://keepassxc.org/>

[2] https://github.com/keepassxreboot/keepassxc/releases>

[3] And -because I'm a Linux user- not only do I have KeePassXC in my package manager, I also know that [1] is listed as its project homepage.

[4] ...which started like four years before KeePassX's final stable release...

[5] https://sourceforge.net/projects/keepass/files/KeePass%202.x...>

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

#609
post #65

Earlier quoted context omitted.

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

I want to like passkeys but I haven't had any success getting them to work. Every time I click on "sign in using passkey" both my browser (Firefox or Chrome, on Android/Win/Mac) and Bitwarden are like "no passkeys found" and I'm never given an option to create one. 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 pr…

I've seen that kind of comments multiple times, and I don't get it.

I use Yubikeys, and passkeys just work. On Chrome, Firefox and Safari, both on macOS and Linux (specifically Alpine). I also tried with iPhones (for my family), and it also just works.

I haven't tried using an Android device, is it what you are trying?

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

#610
post #65

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…

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

All non-enterprise big tech uses of passkeys (Google, Apple & Microsoft Accounts), do not require an attestation statement (or in spec-parlance, use the `None` or `Self` Attestation Types).

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.

Post reply on HN