Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Since support for APP seems to be limited to specific browsers/hardware, why not at least do TFA with a one-time passcode app? That seems to be much more widely supported, and it considerably better than whatever they may/may not be doing today..


That does not guard against the phishing scenario that is one of the biggest threats to campaigns. Any kind of two-factor auth short of a security key is inadequate against that threat.


Why do we need a physical key though? Why don't browsers communicate the url to the password/totp app, and the app only respond or allow fill-ins for matching domains?


Because phones aren't trustworthy. Operating systems can be hacked, privileges can be granted to flawed apps, etc. U2F hardware is single-purpose with a trusted stack end to end.


> the phishing scenario that is one of the biggest threats to campaigns

What phishing scenario, and how is TFA completely defeated by it? The article just says "the best defense against phishing is a 'security key'", but doesn't explain why other options like TFA are inadequate.

I didn't say TFA would be the ultimate solution, but that it's likely to be supported by more things that people use (like apple devices..). If you choose a solution that might be technically superior but require people to make major workflow changes, you'll find they won't use it. TFA seems like a good compromise to me, so I'd really like to understand why you think it is not.


If I show you an impostor website purporting to be Gmail, and get you to type in your password plus authenticator code / SMS code / app notification code, I can get into your email account.

If I do the same and your second factor is a security key, I get a useless binary blob that I can't turn around and hand to Google.

The U2F key gets the actual URL of the page you are on from the browser, so it can't be fooled by impostor websites, however clever. That's the difference, and the reason that Google moved their employees onto security keys. Too many people were getting phished otherwise.


> so it can't be fooled by impostor websites, however clever

Can't this be defeated by DNS poisoning? TLS/HSTS would help, but that assume folks are verifying that the hostname matches the cert... (big assumption)

In any case, I see your point, thank you for explaining it.


I believe there's an additional moving part in the U2F standard (channel ID) that is supposed to mitigate even if someone with a valid cert hijacks the session. But I don't believe it's implemented, and I defer to greater nerds to describe it.


You don't have to verify that your hostname matches the cert. The browser does that for you. That's part of the point.


Not all browsers do that, and many major ones display a warning that users have been trained to click through because of at least a decade of similar browser warnings.


What browsers do not?


NCSA Mosaic 2.0.0 (and all versions prior).


Probably `M-x eww`.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: