Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

Post reply on HN
Print view View original

691–700 of 816 posts

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

#691

Post by growse »

ori_b wrote: post #679
growse wrote: post #677

Earlier quoted context omitted.

I missed a word out from my question. Let me try again. What makes you think that the Webauthn standards are _only_ "targeted at running services for the general public"?

Yeah, so if you want me to trust them, the harmful parts need to get removed from specs used in public contexts. I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec. Passwords suck. It's depressing that otherwis…

> If you make something possible, it will be used.

Sure, but that's not without tradeoffs. I come back to:

> Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

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

#692

Post by Perz1val »

avodonosov wrote: post #263
Perz1val wrote: post #226

Earlier quoted context omitted.

Phising = pretending you're the first party

Tuesday follows Monday

I don't know if you're sarcastic or just missing the problem; which is that people will be presented with lika a facebook login page, on a site with url like `facebook.quick-login.com` or `facebock.com` and they'll enter the passcode since as fair as they were concerned, they did everything correct. The disclaimer does shit preventing that, they »obviously« didn't share the code with any other website, they entered it on the facebooks as they were told!

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

#693

Post by rstuart4133 »

janfromdaito wrote: post #406
FuriouslyAdrift wrote: post #394

Earlier quoted context omitted.

We've had massive problems with moving to passkeys (browser based) at our company and moved back to an app based Authenticator. Everyone is accepting of the autenticator app or uses a yubikey.

What were those "massive problems"?

I'm not the OP, but I expect it the same issues that have stopped me from using passkeys now.

His reply does give one aspect of it: passkey's are fragile. To be secure, they can't be copied around or written down on a piece of paper in case you forget, so when the hardware they are stored on dies, or you lose your Yubikey or is as he described the PC re-imaged, all the your logins die. That will never fly, and it's why passkeys are having a hard time being adopted despite them being better in every other way.

Passkey's solution to that is to make them copyable, but not let the user copy them. Instead someone else owns them, someone like Google or Apple, and they will do the copy to devices they approve of. That will only be to devices they trust to keep them secure I guess. But surprise, surprise, the only devices Apply will trust are ones sold to you by Apple. The situation is the same for everyone else, so as far as I know bitwarden will not let you copy a bitwarden key to anyone else. Bitwarden loudly proclaims they lets you export all your data, including TOTP - but that doesn't apply to passkeys.

So, right now, having a passkey means locking yourself into proprietary companies ecosystem. If they company goes belly up, or Google decides you've transgressed one of the many pages of terms, or you decide to move to the Apple ecosystem again you lose all your logins. And again, that won't fly.

The problem is not technological, it's mostly social. It's not difficult to imagine a ecosystem that does allow limited, and secure transfer and/or copying of passkeys. DNS has such a system for example. Anyone can go buy a DNS name, then securely move it between all registrars. There could be a similar system for passkeys.

Passkeys have most of the bits in place. You need attestation, so whoever is relying on the key knows it's secure. The browsers could police attestation as they do now for CA's. We have secure devices that can be trusted to not leak leak passkeys in the form of phones, smartwatches, and hardware tokens. But we don't have a certification system for such devices. And we we don't have is a commercial ecosystem of companies willing to sell you safe passkey storage that allows copying to other such companies. On the technological front, we need standards for such storage, standards that ensure the companies holding the passkeys for you couldn't leak the secrets in the passkeys even if they were malicious.

We are at a frustrating point of being 80% of the way there, but the remaining 20% looks to be harder than the first 80%.

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

#694

Post by kbolino »

daneel_w wrote: post #687
kbolino wrote: post #678

Earlier quoted context omitted.

Right, but peppering was not part of my comment. You can't always pepper, and there are different ways to do it. It's (mostly) orthogonal to the matter. You do not have to do any transformations on the input when using Argon2, while you must transform the input before using bcrypt. This was, again, an unnecessary and dangerous (careless) design choice.

I don't understand your responses here. Clearly you are not familiar with what problem peppering solves, or why it's a recommended practice, no matter what self-contained password hashing you use. bcrypt, scrypt, Argon2; they are all subject to the same recommendation because they all store their salt together with the digest . You can always use a pepper, you should always use a pepper, and there's only one appropri…

There are at least as many ways to pepper as there were to salt before salts became integral to the definition of a good KDF. To wit:

  KDF(password, salt XOR pepper, ...)
  KDF(password + pepper, salt, ...)
  KDF(password, AES128(salt, pepper), ...)
  KDF(HMAC-SHA256(password, pepper), salt, ...)
  ...
And no, you cannot always pepper. To use a pepper effectively, you have to have a secure out-of-band channel to share the pepper. For a lot of webapps, this is as simple as setting some configuration variable. However, for certain kinds of distributed systems, the pepper would have to be shared in either the same way as the salt, or completely publicly, defeating its purpose. Largely these are architectural/design issues too (and in many cases, bcrypt is also the wrong choice, because a KDF is the wrong choice). I already alluded to the Okta bcrypt exploit, though I admit I did not fully dig into the details.

The HMAC-SHA256 construction I showed above, and similar techniques, accomplishes both transforming the input and peppering the hash. However, the others don't transform the input at all or, in one case, transform it in a way even worse for bcrypt's use.

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

#695

Post by Bender »

12ian34 wrote: post #656
Bender wrote: post #421

I don't like any of the methods used today. Passwords are OK for me since I pick strong pass phrases, use different emails per site but for me the superior option for me is IP/CIDR restrictions. A small handful of sites support it and some of those don't expose that they do because some people think a long DHCP lease is a static IP and that can cause a customer support ticket. It was a battle but I have managed to ge…

wow your threat model is very different to me

wow your threat model is very different to me

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.

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

#696

Post by MiddleEndian »

vdfs wrote: post #534
NoGravitas wrote: post #490

Earlier quoted context omitted.

If they are doing this to 125,000 accounts, they should get an average of one account per day, right? So on average it would on average take them 342 years to get any specific account, but as long as they aren't trying for any particular account, they've got a pretty good ROI. I guess the fix for this would be exponential backoff on failed attempts instead of a static quota of 4 a day?

Why would doing this to 125K accounts give them access to one account per day? The chances of guessing 6-digtis pin code for each account is the same (10^6) regdless of how many accounts your are attacking

It's never truly guaranteed and the numbers aren't quite one account per day at 125k accounts, but:

10^6 digits = 1,000,000 possibilities

125,000 accounts x 4 attempts per account per day = 500,000 attempts per day

---

1-(1-1/1,000,000)^500,000 ≈ 39%

So every day they have a roughly 39% chance of success at 125,000 accounts.

---

At a million accounts:

1-(1-1/1,000,000)^(4×1,000,000) ≈ 98%

Pretty close to 1 account per day

Off by a factor of 4 but the concept stands.

---

And 125k accounts will be close to guaranteed to getting you one each week:

1-(1-1/1,000,000)^(7×4×125,000) ≈ 97%

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

#697

Post by anonu »

DecoPerson wrote: post #19

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…

A similar flow can still happen with passwords. Granted, the user may be confused if they use a password manager and the password doesn't populate.

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

#698

Post by ori_b »

growse wrote: post #691
ori_b wrote: post #679

Earlier quoted context omitted.

Yeah, so if you want me to trust them, the harmful parts need to get removed from specs used in public contexts. I would love to use public key cryptography to authenticate with websites, but enabling remote attestation is unacceptable. And pinky swears that attestation won't be used aren't good enough. I've seen enough promises broken. It needs to be systematic, by spec. Passwords suck. It's depressing that otherwis…

> If you make something possible, it will be used. Sure, but that's not without tradeoffs. I come back to: > Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

And I come back to: if it would never work, why not drop support? "We pinky promise" is just not good enough.

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

#699

Post by AgentME »

baobun wrote: post #67
AgentME wrote: post #27

Earlier quoted context omitted.

Passkeys on cryptocurrency wallets such as the Trezor and Ledger are tied to the device's seed phrase and can be backed up.

Did you try that? I can't find any confirmation on if it's actually working for classical keys but it's for sure not supported for resident keys on Ledger. https://www.ledger.com/blog/strengthen-the-security-of-your-... https://github.com/LedgerHQ/app-security-key/issues/6 https://github.com/LedgerHQ/app-security-key/issues/7 Is Trezor implementation more mature?

Damn I misremembered, I've only tried it on Trezor, not Ledger. What I do know is I've successfully used my Trezor for signing in to Google and several other sites through one or both of Chrome or Firefox.

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

#700

Post by parliament32 »

I went hunting in the NIST documentation to see if this is even an approved authentication method and, technically, I can't find anything wrong with it (if we consider it to be a "Look-up Secret Authenticator", see NIST 800-63b section 5.1.2.1). They're technically abusing what is supposed to be a collection of pre-distributed authenticators (think recovery codes), but there's nothing prohibiting these look-up codes from being sent on-demand and there only being a single selection.

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.

Post reply on HN