Comment by fractionalhare | Hacker News Reader

Comment by fractionalhare | Hacker News Reader

Parent Full thread

> Every time PGP for the masses is suggested as a solution it gets dismissed as being to complex or difficult to wrap your head around, but all these scams would not work in a world where authors and publishers only trust signed e-mails.

No, that's not why it's dismissed. Security experts don't advocate for PGP for two reasons:

1. It requires constant vigilance. If humans en masse were capable of constant vigilance in a security context, we wouldn't really have a problem with phishing in the first place.

2. PGP uses relatively old cryptography which is easily misimplemented and doesn't feature forward secrecy. So again to maximize security you have to rely on your users doing something manual: in this case, generating and sharing new keys at some interval, which then need to be verified on the other end etc.

Speaking to the more general point on phishing: people on HN are usually very overconfident in their ability to spot phishing emails. It's easy to spot simple ones reliably. It's fairly easy to spot pretty good ones when you're expecting it. It's functionally impossible to consistently spot very good phishing emails. I say this as someone who has run simulated phishing email campaigns on software engineers in a large tech company. Even many security engineers would get caught out by the best phishing emails, and what's worse: the set of engineers who would be fooled would change depending on the day you ran it.

Humans are fallible. Attackers do not need to compromise most people in your org. They need just one person with privileged credentials to have an off day and not run through an unrealistic checklist, in an organization with hundreds to tens of thousands of people. The best phishing emails will combine excellent social engineering with a legitimate technical break that privileges them to send email on behalf of a domain. You will not spot this reliably, no matter how technically savvy you are. It will pass the technical checks you have.

The best approach to mitigating phishing campaigns is endpoint security. You should obviate the need for employees to even use passwords in a corporate context, and you should use authentication systems which aren't phishable.

> Humans are fallible.

This is the real problem that techies tend to ignore. You can have the most technologically secure communication platform in the world, but it all falls apart the second someone circumvents it. Phishing attacks are usually engineered to convince people to circumvent security protocols.

For example, a phishing e-mail might claim to be the person's boss, claim that the boss lost their phone, and ask someone to send the documents via e-mail "just this once" to close an urgent deal until the boss can get back to the office and work with I.T. to fix their phone. Underlings don't want to get fired for ruining the deal by ignoring direct orders, so they send the documents over.

Past a certain point, increasingly sophisticated security measures begin to increase the chances that someone will choose to circumvent the security protocols. At the extremes, people become so accustomed to the idea that the security protocols are too slow, complex, and failure-prone that circumventing them becomes a weekly or monthly occurrence just to get their jobs done on time. Once you reach this point, it's easier than ever for phishing attacks to convince people to do bad things.

If you try to force everyone to use PGP all the time, you're going to end up with a lot of employees communicating on unofficial channels simply because they want to get their jobs done and move on with life.

I don't disagree with any of those points (except perhaps to point out that always verifying through another channel can still be a viable solution if any breaches aren't too far reaching).

I would like to add that it's easy to be overconfident when running simulated phishing attacks too. At one place, reporting an email as suspicious would trigger a scan of the email which crawled every link, including the /phished/<my-unique-guid> links. The people with the worst scores were precisely those who followed corporate policy to the letter and reported every suspicious email. It took about one cycle of that nonsense before everyone had email rules deleting the simulated phishing emails.

> You should obviate the need for employees to even use passwords in a corporate context, and you should use authentication systems which aren't phishable.

What are best practices or products for this?

1. Two-factor authentication enforced on everything.

2. Access control policies which minimize privileges to only those which are needed.

3. Put everything behind corporate SSO instead of per-account passwords and login pages.

4. An authenticating proxy that enforces policies on each individual machine using something like webauthn.

The first recommendation limits the extent to which accounts can be compromised if users mistakenly enter their passwords. The second limits the damage which can be done when accounts are compromised. The third limits the general attack surface of passwords entirely, as does the fourth. In particular: the fourth also allows you to remove your corporate VPN while leveraging SSO. It also makes it easier to enforce the granular access control policies.

These things can be a heavy upfront technical investment, but there are off the shelf solutions and products for each of them. They're also easier than trying to train humans to be superhuman.

https://www.okta.com/passwordless-authentication/

security keys maybe? Seems hard to phish a physical key touch.

The key touch is mostly irrelevant, much bigger win is that the protocol actually verifies the domain it’s authenticating against.

A key touch on fakegoogle.com can’t be proxied to authenticate on google.com

WebAuthn is the mechanism that cares about DNS names. The Security Key - as a separate piece of hardware implementing CTAP2 (Client To Authenticator Protocol 2) - is not able to itself verify which web site you're visiting.

So, that verification step takes places inside your web browser. In this specific context this means a vulnerability is that your employees might install software which is also able to perform the same steps but unlike say, Chrome, does not do DNS name checks, perhaps it even intentionally always tries to generate authentications for google.com.

On a very locked down platform, such as an iPhone, or some employee laptops in corporations where employees aren't trusted to install software, there should be no way for that software to run. On Android, Google get to bless binaries with the privilege to do this, they bless the built-in Android browser, Chrome, production builds of Firefox, and I suppose it's likely there are similarly popular browsers I haven't heard of, but there is no way for a normal out-of-box Android device to just install some garbage adware that does WebAuthn even with a manual APK install. If you lack that privilege, when you ask Android to talk to a Security Key it fills out the parameter where a DNS name would go with a per-app ID. So you can use Security Keys to do cool stuff from an app, but you can't fake WebAuthn.

e.g. you can work out the ID assigned to your app, get the backend code your server people wrote for WebAuthn, and spin up another copy that checks that ID instead of your DNS name, now you've got a one touch in-app sign-in that works with fingerprint sensors on popular phones the same way WebAuthn does for your web site.

The user presence detection means that even if the DNS name matching mechanism is defeated (e.g. you have software install privileges because you work in the IT division, you install software from a phishing mail) the user needs to actually touch the sensor/ press the button/ whatever to signify presence, which requires further social engineering each time. In a spear phishing attack this is definitely conceivable but it's one last opportunity for your victim to say, hang on, what's going on here?

User Presence is a signed bitflag (it's also mandatory on most of the cheap devices anyway) which means it can't be faked even on the cheapest possible CTAP2 implementation, and a WebAuthn server implementation can have confidence in the value of that bitflag when received, the WebAuthn spec. says the implementations should reject authentications where that bitflag is not set.

right, good point

Reply on news.ycombinator.com