141–150 of 289 posts
how about use 3-step auth? 1. you input your username google send back an msg/pic which you saved in google at last login confirm then goes to step 2 2. you input password 3. google ask you input auth code
Earlier quoted context omitted.
I was think more of a specific mail scanning process for images that look exactly like UI elements, with some fuzzy match. If it matches, flag it with the usual warnings. It feels like there's at least the potential to explore options.
Why don't just put a little frame around embedded elements like pictures, etc? Maybe with a little icon indicating the type.
Pragmatically I think Browsers disabling the rendering of data:text/html is a better approach. The breakage is minimal and it would catch more phishing attacks than just ones that originated from emails with images embedded.
There is also a password alert chrome plugin by google [0]. If you ever enter your google password on any domain other than accounts.google.com. It will immediately alert you and give you a link to change your password. It can handle multiple passwords too if you have multiple google accounts. [0] https://chrome.google.com/webstore/detail/password-alert/noo...
Still useful, I guess, because it lets you know immediately what's up, so you can send out emergency emails to your contacts.
I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…
I use 1password, which will only fill in the password associated with the current domain.
Earlier quoted context omitted.
Why is data:text/html even valid or rendered to the page in the first place? I'm having trouble coming up with a valid usecase for this
It's just not treated as an exception. Works for all MIME types supported by the browser.
And also, why not do something like this even. Let the browser save screen shots of some user selected sites. Like mail login page, online banking login page etc etc and have them map to a trusted url.
After loading a page, browser should screenshot the page and use some ML magic to compare it to the stored screenshots (I mean, there are things today that can call out the names of the things in an image and even what tell they are doing, right?). When one of them matches and If the url of the current page differs from the trusted url, the user should be alerted..Something like "Hey user, this page suspiciously looks like this page that we stored, but the url is completely different. Are you sure about this?"
Correct me if I'm wrong, but that embedded image (pretending to be an attachment) redirects you to a (fake) Gmail login page. How is that supposed to trick anyone? I mean, isn't it unusual (i.e. never happens) for attachments to take you to a Gmail login page? So that's suspicious behaviour right there. How is it a serious phishing attack that's getting so much attention on a platform like HN where people are used to…
Earlier quoted context omitted.
This is definitely true of TOTP but U2F was designed to prevent phishing attacks by incorporating the hostname in the protocol[1], which means the attacker needs to successfully compromise SSL as well. 1. https://security.stackexchange.com/questions/71316/how-secur...
Very clever, thanks for sharing. However I wouldn't want my second-factor to be attached to my browser. Seems way too volatile for me. Personally I'd rather keep TOTP and be vulnerable to time-of-use phishing. Maybe if the browser had an OS API that a YubiKey could query...
This is a lesser-known benefit of password managers that autofill (or at least auto-look-up) passwords in web pages. I might fail to notice a wonky address bar, but 1Password will notice.
It converts the n-websites-n-passwords situation into one where passwords become random tokens unlocked by a single client-side secret.
We need to make U2F more widespread.
