91–100 of 217 posts
Earlier quoted context omitted.
Not if the phising site asks for the 2FA token.
The point of 2FA is challenge-response and the secret key is in the token. If a phishing site asks for 2FA it can get only one valid challenge-response pair, not the secret key.
U2F cannot be phished.
Earlier quoted context omitted.
The point of 2FA is challenge-response and the secret key is in the token. If a phishing site asks for 2FA it can get only one valid challenge-response pair, not the secret key.
One login is enough to authorize an Oauth app.
This is the second extension that I use on chrome that has been hijacked. The first was live http headers [0] I have never had this experience on Firefox. Is it simply a matter of Chrome being a bigger target? [0] https://www.webmasterworld.com/webmaster/4829365.htm
Earlier quoted context omitted.
Only with U2F, because the hardware dongle would refuse to provide the OTP to a different domain
Yeah, we really need to distinguish between a 2FA app and a dedicated hardware key. My phone is probably the least secure thing I've ever owned, both in terms of technical security, and physical security. This whole 2FA thing has been really jarring for me, because I always treated my phone like a public space: no password, no private data (that I know of), ready for inspection by foreign authorities. Of all the thin…
[1] https://en.wikipedia.org/wiki/Security_token#/media/File:Cry...
Instead, Google should generate an emergency disable code that a developer can put into a simple web form from anywhere in the world, even if the developer has been locked out of every one of their accounts, which immediately centrally disables that extension.
How it should work.
Parts.
1. "revocation code generation" and explanation. Text like: "this is a secret revocation code. Anyone who learns it can immediately disable your extension. Keep it secure and separate from all of your production systems. You will be able to use it even if locked out of all other acccess."
2. A web form people can submit revocation codes to, from anywhere with Internet access.
The code should be very high-entropy and generated by Google. However, it should not have ambiguous characters like 1 and capital I.
I personally would generate it using a dicewords-like wordlist. Also, I personally would ensure it had approximately 384 bits of total entropy of which one third is a recovery checksum. This enables the developer to write many words down wrong and still be able to disable their extension. In case the recovery record/checksum portion were used, I would offer the user the result "You appeared to have made a mistake which we could correct. Is this the correct disable key?" then show the corrected version.
However, this last idea seems to be beyond the state of cryptography worldwide (i.e. for some reason I have written something that exceeds best practices worldwide, like I'm from the future or something), so I understand if Google's cryptographers don't implement this part.
The above seems a bit grandiose of me so here is the comment where I first wrote about this:
Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action. While this will be an interesting UX challenge, defaulting to domain-specific permissions is the sane thing to do in this age. Case in point, I don't care about a readability or bookmarking plugin…
Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action. While this will be an interesting UX challenge, defaulting to domain-specific permissions is the sane thing to do in this age. Case in point, I don't care about a readability or bookmarking plugin…
Side note: Chrome appears to have moved Extensions out of Settings since I last looked, and the "search settings" bar doesn't bring it up either. Took me a few minutes to find how to get to them.
Earlier quoted context omitted.
>> The only real defense is to glance at the url bar every time you're about to enter your password With Google specifically, the worst part is you really do have to look at the URL every single time you go to enter your password. And by that I mean that if you land on the login page, verify the URL, enter your password, submit, and get the error page saying you got the password wrong... you must check the URL again…
Physical keys would solve the problem of redirecting to a fake page (and maybe they would make 3-rd party auth protocols like OAuth or Github login unnecessary).
Earlier quoted context omitted.
Only with U2F, because the hardware dongle would refuse to provide the OTP to a different domain
Yeah, we really need to distinguish between a 2FA app and a dedicated hardware key. My phone is probably the least secure thing I've ever owned, both in terms of technical security, and physical security. This whole 2FA thing has been really jarring for me, because I always treated my phone like a public space: no password, no private data (that I know of), ready for inspection by foreign authorities. Of all the thin…
Because it's the only instance of a computer that you can expect majority of users to own and always have on them.
2FA as a thing would not get any reasonable adoption if you required people to buy hardware keys to use it. Not to mention, hardware keys do not work on every device one would like to log in from (AFAIK you can't plug in a Yubikey to an Android tablet, and it may not have NFC built in).
Earlier quoted context omitted.
The point of 2FA is challenge-response and the secret key is in the token. If a phishing site asks for 2FA it can get only one valid challenge-response pair, not the secret key.
SMS and TOTP (Google Authenticator) can both be phished. U2F cannot be phished.
What if I control the user's computer and can let my own code interact with U2F? Or does the protocol somehow prevent that?
