Live data from Hacker News

That's not how 2FA works

shkspr.mobi

171–180 of 269 posts

Re: That's not how 2FA works

#171
post #144

Earlier quoted context omitted.

2FA absolutely will protect you from a phishing site using the password it stole. Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.

> The solution is to go only to the right site. i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors. So no, that is not the solution.

Well, name one error that persists despite not making the error, and you can definitely say I'm wrong. But that wasn't the point. The solution is to go to the right site. You were supposed to use your imagination to come up with ways that might be caused to happen. The article and commenters here suggested password managers that discriminate between the right site and the wrong site, that's an example. "OH SURE BLAME THE VICTIM FOR NOT INSTALLING A PASSWORD MANAGER!" If you're looking for a solution that doesn't whatsoever require the participation of the user, you may meet with some degree of disappointment.

There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.

Re: That's not how 2FA works

#172
post #100

Earlier quoted context omitted.

I don't think the kickstarter is relevant now. You just buy them from solokeys.com. There's been Somu since that, and Solo2 is in the offing, with plenty of storage, apparently. I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version). In answer to the expense question, two Solo keys appear to set you back 38 qui…

I can confirm what you and _wldu are saying and yes, the latest project is https://solokeys.com/v2 and is launching end of this month. From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive. First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs Next, it's features. To st…

Ah, I didn't know about the PGP code size. Point taken about the cost, and I hope you can sell to organizations. I'm surprised I can buy a competitor for £8, but then I can't run the proprietary programming software or, I assume, re-flash it. I'm happy to support a free software project anyhow. I wish I could register my Somu with the work Duo system rather than the display-a-number-you-type HOTP keys they reluctantly issue as the expensive alternative to expecting us to use personal phones for such purposes. Phishing, we've heard of it.

Re: That's not how 2FA works

#173

Earlier quoted context omitted.

> The "they just use your login token" is akin to "they just hacked the CIA's database". Just. He's saying that they can basically MITM you, which is true. GitHub asks attacker for token, attacker asks you, attacker gives token to GitHub on the spot, presto.

Ah, I did overlook that one. That said: I remain unconvinced that 2FA is a trivial thing to beat. Now we're talking about an active attempt to impersonate you , as opposed to a general catch-all-the-2fa-less-logins Put another way: If you ran this phishing site, would you focus your time on the logins with 2FA enabled (which if I've understood correctly means you'd have to catch them in the window the token is valid…

If you use your phished credentials immediately (e.g. inline with it being phished), then it doesn't make a difference if they are using 2FA. You use the credentials they entered to login from a backend system automatically, and then if that ends up with a 2FA prompt, you show the victim the 2FA phishing page next, instead of redirecting them to the real app/whatever.

This obviously does have its own downsides (you have to maintain a login infrastructure, as well as your phishing infrastructure), but this was even seen before 2FA became common to detect if an incorrect password was entered into the phishing site.

It is definitely an improvement, but TOTP doesn't provide much protection from phishing, and as it becomes more popular more phishers will need to accomodate for them in their campaigns, further reducing their effectiveness here.

Re: That's not how 2FA works

#174

Earlier quoted context omitted.

Yes. You must have at least two keys registered. However it’s worth noting that most services do not offer priority. Meaning you can use either one. I think it makes sense to designate back up keys and only to be used when user reports lost/stolen primary key.

But what is the story there? You have a backup key, hopefully stored "off site", now you want to enroll in another website. You have to get that backup key before you do that? Or bookkeep which sites you have on the backup key and which you don't?

This is a very good point and perhaps something Yubikey and similar services should consider: paired keys. Once paired the backup can always replace original if user reports it missing or lost regardless of when they were paired.

Re: That's not how 2FA works

#175
post #121
post #104

The linked article is correct, but uncharitable. It correctly states the behavior of two-factor auth systems but incorrectly understands their value . Yes, 2FA won't protect you from being phished by a site if you aren't careful. 2FA absolutely will protect you from a phishing site using the password it stole. So no, when someone says "Use 2FA if you might be phished" you shouldn't be replying "That's not how 2FA wor…

Also, I'm a big fan of U2F keys including Yubikeys. I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it. For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS veri…

> I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.

Really? How? Last time I tried to do this it turned out that apps/sites would not send to these virtual SMS numbers.

Re: That's not how 2FA works

#177
This is a good article about the weaknesses of the trust models of navigation on the web. The author uses a password manager that also fulfills the role of a personal 'have I seen this site before?' database, which helps them associate a URL to its conceptual entity, in their quest to determine if the site they visited was the site they intended to visit.

In this exact form, this is a feature that's absent from mainstream browsers today. Because browsers do not have this, people instead turn to all sorts of other signals to judge the site's identity, but each one of those signals is designed for another purpose, and ought to not to be used directly by the user to make such determination. But no other signals are available, so they get used nonetheless.

Some people look at the URL before clicking it, or the URL bar in the browser after they've already navigated to the site, and try to judge from the URL whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including: (1) people often read visually instead of comparing codepoint-by-codepoint, so reading errors or homoglyph attacks are possible, and browsers can only meaningfully mitigate against the latter; (2) very few people keep a computerized allow-list, so they check against expectations in their head; and (3) some organizations will make use of domain names that greatly differ from their own name, which works contrary to the instinct of a URL-judging user who consider themselves 'cautious', and it's difficult to stay aware of all this.

Some people look at the TLS certificate, and try to judge from the information displayed by the browser about the cert whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including (1) DV certs only prove that someone (i.e. anyone) had control of the domain at the time near the cert's issuance, so its value as a trust signal to the user ought to be zero and immediately reduce to the prior case of mentally validating the URL by its character content; (2) EV certs validate against a legal entity in some jurisdiction, but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-by-juristiction registries of legal entities are a tool for a different use-case and were never intended to collectively ensure globally unique Organization names; and (3) in their rush to ensure widespread TLS deployment on all sites, and their involvement with efforts to bring short-lived cost-free DV certs to everyone, browser-makers began de-emphasizing the UI distinctions between DV certs and EV certs some time before the true shortcomings of EV as a user-facing trust signal were widely demonstrated.

Some people look for the visual design of the website. This is trivial to fake.

Some people will rely on browser-resident bookmarks, browser history, or 'top sites' tiles to navigate to common sites they've visited before (or to sites the browser-maker pre-loaded into the listing). This is a great way to preserve the trust chain and reduce the likelihood that the user arrives at an unintended site by mistake. But these features do not directly address the case of a person navigating to a URL they were linked or provided from an arbitrary source, such as the example raised in the article.

Building blocks exist today that could be used by publishers and browser-makers to aid users in judging URLs. Some of these will require past UX decisions to be undone.

For example, top sites could become their own Root Certificate Authorities [1] and be listed in browser trust stores; these companies would be expected to issue certs for sites associated to themselves. This would eventually reshape the cert landscape so that a parent-child relationship between issuer and subject could be meaningfully distinguished from a 'provider and customer' relationship. Companies that provide services to others, such as payment processors, could also become root CAs and sign for their customers. These changes, and a browser UX that once again shows the cert issuer, would go a long way towards reducing the likelihood that users are fooled by sites trying to impersonate top sites.

If this were to come to pass, other CAs would be expected to pivot to minting certs that play the role of a trustmark, by conferring a degree of ongoing assurance that's useful to the user (which, in fairness, was the original point behind EV certs). They would do this by establishing strong brands around their trustmark, issue certs for a short lifetime, and monitor the site on an ongoing basis to see if it's still deserving of their trustmark. This would result in a business model similar to those of EV certs, but a trust model that's based on the user's trust in the CA's exercise of good judgment befitting their brand.

[1] https://news.ycombinator.com/item?id=13495262

Re: That's not how 2FA works

#178
They author makes a few good points, but I find the author's critique of Yubikey weak:

>Cost. The average YubiKey is £50...

If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain.

>Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.

Pressing the button at the right tight was a joke, right? Although, I admit it may be challenging for people with disabilities. Websites making it hard to find 2FA settings is not a Yubikey's problem, it's a website problem. Setting up a Yubikey is rather straight forward too. The main issue is the inability to clone a Yubikey programmatically, but that's the price of security.

>Convenience. My YubiKey is on my keyring. My keys are in my coat...

That's can't be serious too. I won't even elaborate on this.

>Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.

That's actually the only valid point I somewhat agree with. Again, this is largely mitigated by developing the right habits. You don't leave your car keys hanging in your car's lock after leaving the car in a parking lot, right? Then why do it with Yubikey? If developing a new minor habit represents a problem, then either you underestimate the risks, or undervalue your information.

An additional password/fingerprint protection would be nice though. I agree on that.

>Support. WebAuthn is a great standard – but only a few sites support it...

Again, this is not a Yubikey's problem. It's a website problem.

Re: That's not how 2FA works

#179

They author makes a few good points, but I find the author's critique of Yubikey weak: >Cost. The average YubiKey is £50... If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain. >Usability. Buy a device, register it, install the app, configure it, find the setting in the website…

> YubiKeys have no password lock of their own

I don't know if the author of the blog post means something else but if you're using 2FA tokens (i.e. Yubikey Authenticator) you can put password protection for additional security.

Re: That's not how 2FA works

#180
post #169

Earlier quoted context omitted.

Actually better education and training is often the only real solution. It isn't "victim blaming" if the situation is at least theoretically within the victim's control. If some random "plumber" that I didn't call for shows up at my house, asking to be let in to replace some of my pipes, and I say "okay", then he robs me, is it victim blaming to say perhaps I should have been more suspicious of strange plumbers rando…

> education and training is often the only real solution No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination. The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not co…

Explain how any solution prevents the user from opting out of yubikey and typing self-XSS into Dev console to get owned.

Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.

Post reply on HN