Hacker News Reader

Comment by hartator | Hacker News Reader

I don't think more policies will make a better place. One of the team member screw up and stuff like this happen. I am questioning his security education to have been phished so easily.

View on HN

It's counter intuitive. I bet you $5 that if I target you, and you're not expecting it, I can phish you. I've seen this happen in the field, and it doesn't have much to do with education. Relax for an instant and I have you.

The only real defense is to glance at the url bar every time you're about to enter your password. And even I find myself not doing that 100% of the time. It's a numbers game.

A policy of popping up a popup "glance at url bar" every time you copy your password from your password manager (which you're using, right?) would go a long way.

Lastpass will tell you whether it recognizes the site when you go to fill in the password (yes, I use it despite the scary stuff, I know I probably should switch to OnePassword).

Do other password managers not do that?

Just curious, not trying to engage the bigger question of whether getting phished is the user's fault.

I use KeepassX, mostly because it's small and nearly impossible to attack. But I understand the desire for convenience, and as you say, there are some advantages to other managers.

One password has similar behaviour as well as verifying the integrity of the browser[1]. It's not perfect, I'm sure a malicious extension would be unimpeded, but these little features all added up and eventually made me switch.

[1] https://support.1password.com/code-signature/

Take a look at lesspass

No, not that I've seen. lastpass has issues, but it also has some pretty advanced stuff.

An email from Google with a bit.ly link? Hell no, I hope I won't fell from it in whatever situation.

I agree that any defense is far from being perfect, but IT professionals shouldn't fell for an unsofiscated attack like this even if you are no working in security. I am not even talking about a web developer.

And you would be wrong about that. They do. All the time. Spear phishing is still the most effective way for foreign nationals to breach US companies.

Now, there are two ways to deal with the situation. Demonize, or accept. The demonize/blame approach doesn't work.

> An email from Google with a bit.ly link?

The article clearly explains that "the bitly link was not directly visible in the phishing email, as it was an HTML-email."

Disabling HTML e-mails does not sound particularly unreasonable. There’s little additional benefit from them but a whole host of possible issues, least of all that suddenly your e-mail client has to deal with properly parsing HTML and you have to decide whether or not to load remote images and potentially execute JavaScript.

I've never read my email in HTML, mostly for security reasons such as this incident. For the rare occasion where an email doesn't render correctly, Thunderbird's "Show HTML" button works a charm.

Have I been able to convince a single customer (I run a computer services business) or friend to follow my lead? Nope, not a single one.

I have no idea why your post was downvoted. Your post is clearly correct.

> The only real defense is to glance at the url bar every time you're about to enter your password.

With i18n not even that: https://www.theguardian.com/technology/2017/apr/19/phishing-...

Benign POC: https://www.xn--80ak6aa92e.com/ (open it and it'll look like a normal "l" in the url box)

Browser shows https://www.xn--80ak6aa92e.com to me, Chrome on Android. What browser are you using that shows non-ascii with .com?

Firefox for android at least shows it as Unicode

Firefox on OSX shows it appearing as "www.apple.com"

Same, FF54.0 on Ubuntu 17.04.

I activated it so it would display the punycode. Every major browser up to few months ago would show it as "apple", not sure now. But we know many people cannot just upgrade their browsers, so there must be still many vulnerable browsers out there.

Latest Chrome and Safari shows that as https://www.xn--80ak6aa92e.com, no puny code

>> 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 before re-entering your password.

Why? Because Google's login, by design - and repeatedly defended by them as being "acceptable" - allows redirecting off Google's properties after login. So hackers send you to the real Google login page, with a post-login redirect to a fake but perfect copy of the "wrong password, try again" page, where they then capture the passwords of people who mindlessly re-enter their password without double checking the URL a second time.

Most importantly, 2FA does not help you here. You'll enter a currently valid 2FA code on the hacker's site, and they will immediately use that code to actually log in to your account. Before you realize what is happening, you are already locked out of your account - new password, 2FA stripped or replaced, security questions changed, and all pre-existing sessions/devices wiped.

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).

U2F physical keys specifically. Physical keys that generate OTPs would not protect you.

U2F is a second factor which can't be easily phished. If you are using a service which supports U2F and care a minimum about being secure, enabling it is the least you should do.

Pretty sure Google and other sites will do another 2FA challenge when you try to remove or change the 2FA challenge.

The phisher just shows you a "password incorrect" message on the first attempt. Assuming you made some typing mistake, you enter your password and 2FA again...

Most do not, and even Google doesn't. I just verified on my account. You only need to provide your password to access account settings. Completely stripping all two-factor authentication requires no additional 2FA code.

Mmm, maybe. I'm certainly not immune to being fooled. I am careful, however. I roll over and check any link in an email before I click it, and I know when I am or am not authenticated into one of my google accounts. It's all too easy, though, to make a mistake like this when you're in a hurry or don't give something enough thought. The email was very good but after reading it a couple of times the language strikes me as not _quite_ right, especially the "unless you fix it" part at the end. Perhaps the key insight is that you have to assume going in that any email you get like this is fake, and then prove otherwise.

That's a good habit, but a good tool to help you avoid getting phished is https://support.google.com/a/answer/6197508?hl=en

It alerts if you enter your google password anywhere but the real google sign in page.

Ah, the delightful irony. Install a chrome extension to warn you if you get owned by a chrome extension.

That seems like something that should be part of Chrome once you login, not an optional extension.

That too can be fooled. Much better to login to your relevant account by manually opening a new tab and navigating to it. In this case one they saw no link and call to action on their Google developer's website they should realize something was a foot.

In this particular case, though, there were enough warning signs that I wouldn't want to run code by anyone who wouldn't notice them on my machine. The email was clearly not professionally written or machine-generated (note the comma inside the quotation marks around the app name; the oblique "fix the issue" doesn't seem like the right expression to match "did not comply with our program policies"), the ID is clearly non-random (a cluster of keys on the left-hand side of a QWERTY keyboard interspersed with a cluster of keys on the right-hand side, as you would get if you mashed keys randomly) and then there's of course the URL shortener link.

I use iCloud keychain. Safari autofills passwords only if the URL matches. If the password doesn't autofill, I know something odd is going on. Makes it trivial to recognise phishing sites like the one from the linked blog post.

> The only real defense is to glance at the url bar every time you're about to enter your password.

No. FIDO hardware 2fa works fine for this.

As someone who's been phished even though I've written article s on phishing in the past, all it takes is a moment of weakness.

In my case everything looked normal at a glance. 2FA saved me but if they'd had asked for 2FA I wouldn't have noticed.

https://blog.greggman.com/blog/getting-phished/

Other people getting phished

https://www.exploratorium.edu/blogs/tangents/we-got-phished-...

A simple policy to add would be 2-factor authentication, no single shared developer account, and (on Google's side), both another security challenge (2FA) and e-mail notification to both a primary and recovery e-mail address when an extension is moved. Pretty sure Google also raises a question when logging in from a new device, e.g. from Russia, or when certain information is changed. (I know Facebook did at least).

You might be surprised: https://pbs.twimg.com/media/CiWPIQSU4AAIndY.jpg

Reply on news.ycombinator.com