I agree with the article's suggestion[0] that 'data:text/HTML' should be changed to amber (or even red)... How often would a non-technical user need to access such a URI? Technical users (the same way they may test insecure sites), would be savvy to this for legitimate means.
This is pretty much a win-win Chrome hot-fix that could be rolled out asap.
What an excellent analysis of the user perception involved and its obvious remedy.
[0] > What Google needs to do in this case is change the way ‘data:text/html’ is displayed in the browser. There may be scenarios where this is safe, so they could use an amber color with a unique icon. That would alert our perception to a difference and we would examine it more closely.
Another issue is that browsers do not display the non-secure http:// prefix in the url bar (which should probably be red and striked through).
As a PoC, I bought the ___domain https.is, and now I can construct urls like https.is//accounts.google.com - which can look convincing when glimpsed over.
Anyone who treats the URI as an opaque string and simply scans for keywords (which is someone falling for the data: trick) is going to be vulnerable to a large variety of attacks, almost none of which the proposed solution solves.
You never know when somebody has access to your accounts. I learned the hard way that someone had access to my Facebook because they watched me type on the keyboard. Had I changed my password monthly, I would have kicked him out after 30 days. As it stand, that person had access to my account for at least a year if not more.
What the FTC link is advising against are corporate policies that require password rotation, because in practice it has been determined that this leads to users selecting even less secure passwords and/or writing down their passwords because they cannot remember them. If a user wants to voluntarily rotate their passwords, then that's in no way a problem as long as they aren't compromising password strength in the process.
You didn't have login alerts or approvals enabled? Those would've alerted you to the need for a password rotation instantly without needing to rotate complex passwords on a regular cadence.
If anything, I'd say your comment hardened my position against password rotation given how many mainstream sites with sensitive data expose extra security measures to their users. Take advantage of all of them!
You don't get login alerts if the person is using your wi-fi, a wi-fi where you once logged in (college, university, work...) or simply a computer you logged in one time (at that friend's place). That person could even disable them and you wouldn't be aware of it.
You can go on to facebook's privacy settings and disown previous logins. You are right that they don't let you manage it with enough specificity to prevent someone who's using the same IPV4 address and browser as you.
I'm running Chromium 54 on Arch Linux, which I am assuming is not affected, since that page only names version 53. Interestingly, there is no certificate problem on a Windows machine on the same network.
A way to mitigate the attack is to use Google's Password Alert extension in Chrome [1]. If you enter your Google password on a non-Google ___domain, it immediately tells you that you've been phished and prompts you to change your password. I use this extension in conjunction with two-factor auth.
Are there legitimate use cases for 'data:...' URIs as clickable links? I understand these URIs can be useful for embedding resources directly into the HTML, e.g. images and icons. But as clickable links, I have only ever encountered them as a means to circumvent popup-blockers. Would it be reasonable for web browsers to offer an option for ignoring clicks on such links?
A big part of the danger of this hack is that it compromises email.
Email is a skeleton key for every other account you own. 2-factor auth can be a pain to use, but at the very least you should always use it to protect your email.
I don't know if this is interesting or helpful, but I made a Chrome extension for helping test email information in Gmail. It would probably help in this instance to notify somewhat that something isn't correct.
I updated it after my initial upload to enable links (defaults to no links but can click a button to enable links). I just haven't gotten around to re-uploading the plugin. After some thought I definitely feel that just removing links altogether was too much. I will update the plugin after work.
No - because the phishing page can act as a MITM attack - where they display the 2-factor login on the phishing page - and post the entered code to Google, confirm they are in (and receive the cookie enabling access) - while displaying the page back to you.
So 2-factor actually provides a false sense of security here.
Edit: unless you have U2F as per @makomk comment below
Are any advanced users on HN that would've overlooked the obvious signs in the address bar?
I mean, you don't have to know what the string 'data:text/html' means, because Google Chrome highlights the 'https' by coloring it green and they even show a 'secure' button right next to it, so the whole area looks fundamentally different.
IMHO only inexperienced users will fall for this. If you regularly look at the address bar before entering critical data into a website, you will get used to the overall look and most likely notice that something is out of order.
Pssh, I'll say it - I'd fall for this, more than 0% of the time. Am I an advanced user? I can try to give you an example of some client side TLS thing I have implemented and we can haggle over where the bar is for "advanced", but give me a Saturday night beer-riddled netflix binge and a midnight email check, I'm clicking this link.
I'd hope my 2FA would freak out, around that point, and save me from myself. I guess it would depend on the type of 2FA.
This is crazy. It's 2017. Why are people STILL clicking links in their E-mail? Have people learned nothing? You don't have to be a "technical user" anymore know know that's a bad idea.
Hell, why do major E-mail clients even allow functional hyperlinks in E-mail? The major E-mail clients could 80% solve phishing overnight by just disabling links. They could probably solve a further 10% by disallowing copying things that look like URLs.
Sorry if this sounds like victim blaming, but at some point, after enough time, you have to eventually go from "victim" to "culpable".
I click the "unsubscribe" link all the time! Not to mention confirmation email links (much more convenient than entering a code they email me), package tracking links, and a whole slew of others.
I don't know if that's such a great security practice. I thought it was pretty common (at least among tech saavy crowd) to not click on Email links, but judging by the responses I guess not. Good luck and wear a helmet, everyone!
You've completely misread the point: it appears -- to the user -- to be a regular gmail attachment. In the attack described, they're intending to click on an attachment, not a link.
Links are pretty integral to the web. If it wasn't email, it would be Slack or social media. Mobile makes the problem worse because you click a big button which scrapes the link and thus can be gamed to look legitimate.
"Design for default-secure" ought to be UX rule #1.
This is pretty much a win-win Chrome hot-fix that could be rolled out asap.
What an excellent analysis of the user perception involved and its obvious remedy.
[0] > What Google needs to do in this case is change the way ‘data:text/html’ is displayed in the browser. There may be scenarios where this is safe, so they could use an amber color with a unique icon. That would alert our perception to a difference and we would examine it more closely.