Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

331–340 of 816 posts

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

#332

Earlier quoted context omitted.

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.

Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.

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

#333
post #302

Earlier quoted context omitted.

That is unfortunate, but that sounds more like a chrome problem than a passkey problem. You would have the same issue if chrome saved your password.

Passkey is a great example of how five kitchen chefs can't make scrambled eggs. Horrible user experience, terrible marketing, no mental model like "your phone is THE key," no tangible or even symbolic presentation of the key.

That’s a lot of anger without a substantial argument. For Apple users, for example, the user experience is very smooth and the mental model is “I use iCloud to store my passcode just like I use iCloud to store my passwords”. If you use 1Password, you’re changing iCloud for 1Password instead.

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

#334

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…

How is it worse than using a password? I think I'm missing something, please explain. 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.

I think GP has the following in mind:

  - user has an account on GOOD.COM
  - user has saved her password in her browser
  - user navigates to BAD.COM
In this case autofilled passwords are safe and convenient since they alarm the user that she isn't at GOOD.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.

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

#335
post #251

Earlier quoted context omitted.

I have 531 logins for varied websites and services. Would you enjoy having to change 531 passkey devices? Me neither. But default login flows in all these sites prompt you to use your current device as passkey by default, so people who don't know better (i.e. a general "everybody") are being gently pushed to do so.

No, which is why there is the cross platform standard CXF which allows for cross platform sharing of passkeys. Apple has announced that support for this is shipping later this year with iOS 26. Google hasn't announced when they are shipping it yet.

Would’ve been nice if the basic UX would have been figured out before passkeys were shoved down everyone’s throats

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

#336
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…

Why would BigTech care about the dozens of users using an open source password manager? What’s their gain from preventing these people from logging in? They love money and don’t care about user freedom, sure. But they’ve shown no evidence of hating user freedom on principle. Every time I’ve seen them actually attack user freedom, there was an embarrassingly obvious business angle. Like Chrome’s browser attestation th…

Because they'd actively have to make their proprietary passkey systems interoperable with password managers. This is fail-closed, not fail-open: If they truly didn't care, they'd also be no incentive for them to implement support.

But I fear it's worse. Based on how past open standards played out, I find it believable they do care - that there won't be an open ecosystem of password managers.

> But they’ve shown no evidence of hating user freedom on principle.

Yes, they did, just see Microsoft's crusade against Linux and the origin of the "embrace-extend-extinguish" term.

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

#337

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…

There will not be a bank to visit.

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

#338
post #140

Earlier quoted context omitted.

bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in a…

Yeah, that's why bcrypt is broken and shouldn't be used today. It had a good run, but nowadays we have better options like scrypt or argon2.

It's not broken. It's just potentially less helpful when it comes to protecting poor guessable passwords. bcrypt isn't the problem, weak password policies/habits are. Like bcrypt, argon2 is just a bandaid, though a tiny bit thicker. It won't save you from absurdly short passwords or silly "correct horse battery staple" advice, and it's no better than bcrypt at protecting proper unguessable passwords.

Also, only developers who have no idea know what they're doing will feed plain-text passwords to their hasher. You should be peppering and pre-digesting the passwords, and at that point bcrypt's 72 character input limit doesn't matter.

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

#339
Relatedly with respect to passkeys, it seems we have the following tradeoff (simplified):

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.

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

#340
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…

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.

Seems very argumentative for somebody who's just saying there's no issue.
Post reply on HN