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

301–310 of 816 posts

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

#301

Post by elteto »

charcircuit wrote: post #272
j1elo wrote: 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.

So until then you have to do what parent said? Change each one individually when you switch devices? Thanks but no.

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

#302

Post by kmac_ »

Hnrobert42 wrote: post #275
smallerfish wrote: post #241

Earlier quoted context omitted.

> Passkeys is the way to go. Password manager support for passkeys is getting really good. 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,…

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.

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

#303

Post by dspillett »

johtso wrote: post #147
sweetjuly wrote: post #123

Earlier quoted context omitted.

Magic links can be used to authorize the session rather than the device. That is, starting the sign in process on your laptop and clicking the link on your phone would authorize your laptop's sign in request rather than your phone's browser. It requires a bit more effort but it's not especially difficult to do.

Wouldn't that be incredibly insecure? Attacker would just need to initiate a login, and if the user happens to click the link they've just given the attacker access to their account.. The reason why magic links don't usually work across devices/browsers is to be sure that _whoever clicks the link_ is given access, and not necessarily whoever initiated the login process (who could be a bad actor)

> Wouldn't that be incredibly insecure?

If done naively with a simple magic link, yes.

> and if the user happens to click the link they've just given the attacker access to their account

Worse: if the user's UA “clicks the link” by making the GET request to generate a preview. The user might not even have opened the message for this to happen.

> Wouldn't that be incredibly insecure?

It can be mitigated somewhat by making the magic link go to a page that invites the user to click something that sends a post request. In theory the preview loophole might come into play here if the UA tries to be really clever, but I doubt this will happen.

Another option is to give the user the option to transfer the session to the originating UA, or stay where they are, if you detect that a different UA is used to open the magic link, but you'd have to be carful wording this so as to not confuse many users.

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

#304

Post by addandsubtract »

mediumsmart wrote: post #291

I think the registration pattern should be - user enters email to register. email is sent to that email with a link to verify. user clicks link. user gets email with username and password to login in to the profile created for them.

This reveals the user's password (even if temporary) in plain text in an unencrypted email. Basically the last thing you want.

A better workflow is to send the user a link where they can set their initial password themselves.

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

#305

Post by spixy »

smallerfish wrote: post #241
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…

> Passkeys is the way to go. Password manager support for passkeys is getting really good. 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,…

Google password manager's pin?

On my Windows laptop that is Windows Hello PIN, not sure about other OSs. And it can be disabled.

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

#306

Post by esjeon »

The actual weak link here is not the procedure itself. It’s the fact that your email services will happily accept phishing mails into your inbox.

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.

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

#307

Post by account42 »

avodonosov wrote: post #269
pjc50 wrote: post #242

Earlier quoted context omitted.

You left out the /s tag. People don't read that bit.

/s tag? Peope do read, if the email is short

They only read what they need to finish what they are currently trying to do, which in this case is the code they need to log in.

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

#308

Post by johncolanduoni »

uyzstvqs wrote: post #292
smallerfish wrote: post #241

Earlier quoted context omitted.

> Passkeys is the way to go. Password manager support for passkeys is getting really good. 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,…

Passkeys are the pinnacle of bad UX. It just works, until the user tries to switch devices, accounts or platforms. The slogan of passkeys should be something like "I don't have a password, it usually just works, but now I changed X and it doesn't work anymore" . Even worse is hardware-based 2FA built into smartphones (also FIDO), as you lose your phone in a lake and now you can't access anything anymore. The way to g…

Apple’s works fine, including when I’m logging on to my windows machine. Opening the camera app is a little annoying, but I don’t have to do it frequently. 1Password works well too and it runs on everything. There’s open source options, but I can’t attest to their UX.

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

#310

Post by serpix »

grahameb wrote: post #261

I recently set up passkey-only sign ins for a webapp I'm writing using Authentik [0](Python OIDC provider, with quite a nice docker-compose run-up, took only minutes to stand up.) It was surprisingly easy to configure everything so that passkeys are the only thing ever used. 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. [0] https://goaut…

so many of these Authentication providers have a hockey stick pricing scheme, where the first few users are near free and when you grow you are going to get mugged and kicked in the groin.
Post reply on HN