While I normally agree, I think it's important that they referred to the specific person without using blaming language. The team failed and screwed up because they had bad policies with their account. The individual team member who was holding the keys when the screw-up happened? Unlucky.
Fix the process, not the people.
It's good that they're not throwing the poor person under the bus.
I agree with you. The email makes the situation appear as a process issue. Based upon the disclosure text, it seems quite possible the person wouldn't normally have clicked on an email text, but did so here based upon process.
The disclosure displayed the attitude that they shouldn't have expected to get phished. It's 2017. Lots of people get phished.
It's pretty straightforward to never click links that arrive in emails, to never enter passwords into webpages that open on their own.
Of course there are technical ways to mitigate this specific attack, but it is more important not to excuse poor Internet hygiene after the fact.
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.
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.
>> 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.
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.
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).
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Fix the process, not the people.
It's good that they're not throwing the poor person under the bus.