41–49 of 49 posts
1. https://chrome.google.com/webstore/detail/password-alert/noo...
"Changing your password every few months is good practice in general." Stop saying that! https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-r...
I still stand by "change your passwords often". 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.
https://bugs.chromium.org/p/chromium/issues/detail?id=594215...
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…
And presumably also Microsoft, Apple, Mozilla, Opera...
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 th…
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 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…
> What Google needs to do in this case And presumably also Microsoft, Apple, Mozilla, Opera...
It's a bit weird from a security point of view that self-XSS is protected in Firefox & Chrome (https://bugzilla.mozilla.org/show_bug.cgi?id=994134 & https://bugs.chromium.org/p/chromium/issues/detail?id=345205), but navigation data-uris are not.
Earlier quoted context omitted.
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.
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.
> The data: URL part here is not that important as you could have a phishing on any http[s] page just as well.”
Calling out the use of data URIs doesn't solve the issue at all. I could just as easily register abc.xyz, pick up an SSL certificate, and send users to `https://abc.xyz//accounts.google.com/ServiceLogin?service=ma... or `https://abc.xyz/https://accounts.google.com/ServiceLogin?ser...
They get a green lock, and that certainly doesn't seem to require the user to overlook any more than the URI in question: `data:text/html,https://accounts.google.com/ServiceLogin?service=mail`
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.
I think most "technical" users would have two-factor authentication enabled which would prevent this type of attack.
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