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.