Hacker News Reader

Comment by H8crilA | Hacker News Reader

Imagine you already know the passwords for many emails, or likely password patterns, from other sources. That's the kind of the attack we're talking about here. Also, those attacks are normally performed very slowly, and probably through botnets.

(And yes, 2FA is the only real answer here, preferably YubiKeys to also defeat phishing)

View on HN

2FA is so, so, so very tiring.. all day long, 2FAing. We need to move past it. And no, I don't have an answer for it.

Passkeys ?

It just needs to be done correctly, not as a "gimme your phone number, peasant" excuse for data mining.

How many computers do you use normally? How hard would it be to link them to your accounts?

Problem is using multiple browsers, or when a privacy-conscious user decides to delete internet history.

> How many computers do you use normally? How hard would it be to link them to your accounts?

I use private browsing exclusively, so, I’d hope that’s difficult link to me reliably.

Well, you if want to both refuse that a site reliably identify you and have a flawless process for identifying you, you'll have a hard time.

> Well, you if want to both refuse that a site reliably identify you and have a flawless process for identifying you, you'll have a hard time.

and yet the digital certificate the government issues me means they can flawlessly identify me, when i choose for them to be able to identify me, rather than by them permanently tracking my machine.

Explicitly allowlisting a particular install of a particular browser isn’t a strong choice when we already have PKI.

In case you refer to incognito/private windows: that's completely useless. All you can hope to get from it is automatic deletion of cookies. Google got a huge fine for tracking everyone in private mode [0] and you can be certain everyone else who didn't yet get dragged to court is still doing it.

[0] https://www.theguardian.com/technology/2023/dec/29/google-la...

It's still exhausting.

Literally every time I pay for something via PayPal on my computer, I need to pull out my phone, find the authenticator app, open it, scroll to PayPal, tap it, see if there's enough time for this code or if I should wait for the next one, type the 6 digits into the site...

I mean it takes half a minute, and this easily gets repeated several times a day if you engage in a lot of transaction-type things. And it's no faster if it's by SMS or by e-mail because I'm still spending 15 seconds waiting for the message, and then opening it, typing, then going back to delete the message so it doesn't clutter my inbox -- half a minute total again.

> see if there's enough time for this code or if I should wait for the next one, type the 6 digits into the site...

In my experience on most services (not sure about paypal specifically) there's a grace period where a code that just 'expired' is still valid for another ~10-30 seconds? So... at least you can skip that part.

Sounds like a good use case for fido authenticators or passkeys.

Have you ever done literally anything that is actually exhausting? Because this.... this is not exhausting.

> see if there's enough time for this code

I haven't tried PayPal specifically, but websites will usually still accept the previous code for at least a few seconds after a new one rolls over

Not to disagree with the cumbersome process - just want to point out that TOTP codes are valid for 30 seconds after the "expire" (60 seconds total). So as long as you are able to remember / copy the digits, there is no need to wait for the next code even if you don't have enough time to type it in. It will still work.

Tangentially, I really wish authenticator apps continued to show the previous code for 30 seconds so I can continue to refer to it for apps that don't allow copy and paste.

I definitely had no idea! Thanks for that knowledge.

I mean there's never been any UX indication at all that that would be the case. I like your idea of showing the previous code -- that would make it very clear.

Good to know.

To be fair, the reason for this is to account for clock desync between systems, so it wouldn't be correct to say it is still valid for 30 seconds where it might not be in reality. Knowing what this actually means requires understanding the implementation of TOTP, so that you are not surprised in situations where it does fail. The existing authenticator app UX is likely correct for the average user.

TOTP codes are actually valid for 90 seconds, 30 seconds either side of when it’s supposed to be displayed (assuming the display device’s clock is accurate to the second), to allow for up to 30 seconds clock skew on either end, in either direction.

Have you tried a password manager? Many of them will autofill the code for you. It makes it quite seamless.

I thought that defeated the entire purpose of 2FA?

That if your password store got hacked, they still wouldn't have access to your separate 2FA device?

It does to a certain extent but it may be a negligible compromise depending on what you use as your second factor.

https://blog.1password.com/1password-2fa-passwords-codes-tog...

A simple solution is 2FA unknown/new devices.

On Apple devices it's super easy, barely an inconvenience

Right now, the web experience for 2FA is very poor compared to using a mobile app.

I wish I could just put my phone on an NFC reader when a site requires 2FA, and then all I have to do is to confirm on the phone itself.

> 23andMe then claims that poor password practices are responsible for this data leak.

My account (now removed) relied on a long, unique, generated password + Apple SSO. I don't see how I could've made my 23andMe account more secure (I'm in the 6mm pool of users, not the original 14k).

You couldn’t but the access they have to your info is limited to only the info you shared with an account that reused their password from another site. If you’re not sharing info with people you don’t know or trust, you’re ok.

> (And yes, 2FA is the only real answer here)

It's not the only answer. You can also use tools that detect and reject insecure passwords, integrate with HaveIBeenPwned to force-roll passwords that have been previously compromised, etc.

2FA would solve a lot of the problem, but it's not the only option that could have mitigated this.

If the passwords are leaked after the user creates their account with your service, you can't go back and re-check their password against HIBP (unless you're inexplicably storing your passwords as plain text or SHA-1). Using HIBP is a partial solution, but not sufficient to prevent a leak like this.

Mandatory 2FA is sufficient, but not very user-friendly.

> Using HIBP is a partial solution, but not sufficient to prevent a leak like this.

I didn't say it was sufficient to prevent this. I said it was another tool that would have mitigated some of this (and which presumably 23&Me did not implement).

You can check against HIBP on login the same as you check on password reset. If password is compromised on HIBP, force a 2FA and a password reset

Ideally MFA should be based on the accounts / sessions risk and not mandatory

That's another step in the right direction, but 23andMe is the kind of service that people create an account for and then don't use for years at a time. Still not a complete solution.

And I agree that mandatory 2FA isn't a good answer either. As someone who uses long, random passwords on all websites, I like to be able to choose whether to add 2FA on top.

It's a mitigation. If 23andme can't show that they at least mitigated the problem then they're going to find themselves in hot water.

Reply on news.ycombinator.com