Especially when IT is more interested in outsourcing every possible service to a different company/domain. Office 365 alone involves a pretty staggering number, including such self-evidently trustworthy gems as "microsoftonline.com", "azurewebsites.net", and "aka.ms". It's hard to keep up with what's legitimate when seemingly everything you do involves a different domain with a different design language and account management process. Then there's the increasingly popular practice of running things "in-house" but actually on some half-assed cloud stack (What the heck are those stupid CloudFront subdomains, anyhow?).

> It's hard to keep up with what's legitimate when seemingly everything you do involves a different domain with a different design language and account management process.

This is so true. When you have app.<appname>.tld, <appname>app.tld, app.<appname>app.tld, cdn.<appname>.tld, cdn.<appname>app.tld, <appname>cdn.tld, <company>.tld, <appname>.<company>.tld, <company>corp.tld, etc, it's difficult for even tech-savvy users to spot fake domains, especially since there can be multiple TLDs used with seemingly no consistency. Then someone comes along and registers <cornpany>.tld, <company>.othertld, or <compаny>.tld (the "а" is a cyrillic "a")...

Even if you try to integrate Oauth so you can tell users "only enter your username/password on auth.<company>.tld", it's not always consistent. Google will require your email before redirecting, some services require an email and a password (whether it's correct or not) before redirecting, others have special company-specific subdomains, and I've seen a couple where you have to click on an SSO link on the login page and type in your company's domain. Then you get services where you type in your username/password into their site and it authenticates through AD or another backend mechanism which never goes through your Oauth flow (my college had O365 setup like this), bypassing 2FA and defeating the "only auth.<company>.tld is trusted" message.

The best solution I've seen for all of this is an internal TLD, but that requires a VPN to access from offsite, you have to maintain your own CA and DNS (which a much greater impact when it goes down), some services will not allow Oauth redirects to them, and it only works for internally hosted applications.

What's particularly annoying is that HR and finance functions are often among the most likely to involve outsourcing, even as they're also the most sensitive. If I wanted to spear-phish someone, it would probably be through something that looks related to a care provider or financial institution that the company uses, not to the company itself.

> It's hard to keep up with what's legitimate when seemingly everything you do involves a different domain with a different design language and account management process.

Seriously, right!

https://microsoftazuresponsorships.com https://getlicensingready.com/ https://sysinternals.com (fairly popular and well-known!) https://www.microsoftpartnercommunity.com/ https://azureedge.net

etc

More egregious to me has always been my various banks which start out at with bankofamerica.com, chase.com etc but after authentication and some hops I'm usually at something phishtastic like bankfrontend.com.

Reading this gives me anxiety.

God the worst of these are the phishing sites using windows.net or hosted on azure with official/legitimate microsoft certs

Google claims they haven't been phished in over a year, since requiring hardware keys for auth.

Google also is running (or claims to be running, I don't work at their IT department) an interesting zero-trust-networking setup involving a lot of on the fly certificate generation and revocation, as well as some SDN trickery behind the scenes. I wouldn't be surprised if that had more to do with their no haxx than 2FA or hardware auth keys.

Link to their somewhat vague white papers on the matter:

https://cloud.google.com/beyondcorp/

Google also does not allow Windows Laptops/PCs anywhere near their campus.

Exactly: Google detected they were hacked by the Chinese government a decade ago ("Operation Aurora" affecting a lot of other companies including Adobe, Juniper, Rackspace, Yahoo, Symantec, Northrop Grumman, Morgan Stanley, Dow Chemical).

Google stopped allowing Windows to be used within the organisation in 2010 as a response.

I think any other organisation that continued to use Windows values features more than they value security (and I believe that is still the case: you can't secure Windows, Office or Microsoft browsers against state level actors).

Source? Looked online and couldn't find anything apart from one or two untrustworthy mentions on quora.

I doubt anyone from Google is going to publicly comment on their internal security policies, but AFAIK this is a known fact for many years. I'm sure there's plenty of people who work for Google who can comment anonymously.

Security by obfuscation of techniques involved. Classic trick. It's the best so long as each security measure and their interactions are fairly secure.

I would say obfuscation is a valid strategy if also coupled with good security practices / algorithmic security. You're no less secure than if you were using the common flavors of good security practices (assuming you didn't create a mistake in rolling your own, which is a difficult assumption) but the effort required to target you is much higher than normal, and you are somewhat shielded from blanket-applying zero days.

Can you help me understand how those relate to each other?

For instance, someone gets a malicious email, and clicks on a link which downloads a bit of code the exploits a bug in the software to install something, perhaps a key logger or screen reader.

What on earth does hardware keys do to eliminate that?

Seriously, I can’t make the connection (and if I understood I’d probably roll that out across my firm tomorrow!).

I phished for your login credentials, and I get them, but there is no way for me to effectively use them because there is still the hardware key step, which I do not have.

Malware downloads is a separate issue from phishing schemes.

Right, and even if they completely root an employee's laptop and phone they still can't get into the hardware key. Sure, they can "boop hijack" the key by popping up a convincing fake login prompt, but they have to synchronize their schedule to the employee they want to hijack and pull off a convincing fake login prompt each and every time they want to login, so the logistics are still much more challenging than copying a OTP seed.

Why go thru all that trouble when you can just phish with malware?

I’m reminded of back when Kevin Mitnick said it wasn’t that he was a great hacker, but that he was good as social engineering. What made him good was that he took the easiest way in, which is kind of what my point is. I don’t care if you block the hardest hack - I care about blocking the easiest.

(FWIW, I am a huge fan of 2FA, I just don’t understand how it stops phishing.)

You're moving the goalposts. GP was just explaining why base level phishing has been elevated to a higher difficulty level than without U2F.

The way U2F prevents phishing is by binding auth requests to the requesting origin and generating unique key pairs for each origin, so it doesn't matter if the user is convinced and manually activates the key, the phishing site gains nothing it can use on a different origin—even in real time.

Thank you. Indeed I was missing that - your last sentence in particular.

> I don’t care if you block the hardest hack - I care about blocking the easiest.

My entire argument was "with U2F, this is the easiest hack, and it is very hard."

What do you think the easier alternative was?

The word "phishing" has many definitions.

One definition is tricking users into giving valuable information (such as passwords, 2FA codes, bank account details, credit card numbers, social security numbers, etc). Malware doesn't meet this definition of phishing.

That's interesting. This should bring us to the realization that we should think of this as an engineering problem, rather than having an expectation of humans being "bug-free".

We definitely should! The current state of infosec as practiced, regarding, say, vulnerability to email trojan horses, is like using sharp knives for door handles, that instead of just mangling your fingers make a copy of the door keys and mail them to people who sent you emails. And then insisting that repeated user training is enough, and a cost-efficient counter-measure. Even in the face of repeated evidence that it's not.

A rested, focused, well-trained human is almost bug-free. No one is rested, focused or well-trained 100% of the time.

Well, after everybody and their mother pushed for 2FA they realized people can still get phished for the 2FA token, so...

If the service that you're running is not made by idiots that will store your password with anything weaker than PBKDF2 then a strong (unique) password is still a good bet.

Human factors are an issue and I believe lack of enforcement and prosecution is another issue.

To me it is obvious that passwords are insecure. Just think how many people are saving them in a browser without a master password, share them in internal chats, use same password everywhere because it's difficult to remember several passwords etc.

http://knowbe4.com has a pretty good training platform for creating more security awareness and for testing your users with generated phishing emails.

Which ends up being darkly hilarious when they're whitelisted, leading to a situation where literally every "phishing attempt" an employee ever sees is a fake crafted to conform to the stereotypes given in the training.

My employer uses PhishMe. Every "phishing attempt" I see is from my own employer. It is not adaptive. They don't scale up the apparent sophistication of the attack if previous attempt didn't work. So I am continually getting e-mails from "HR" asking me to update my contact info, or from "Expense Reports" asking me to verify some info to get reimbursed for my travel expenses.

It's annoying.

Indeed. I setup a rule in outlook to look for knowbe4 in the header to dump those. Although, to be fair, I doubt it is the devs they are worried about.