[lazaroclapp]

We keep treating falling for phishing emails as a user error. But, perhaps, having our most "official" means of communicating online (email) be a protocol that has no identity verification, no authentication and no encryption, is actually a technical bug, not a human one.

I mean, you would expect that we should at least be able to tell that if you get a [e-mail] email in your [e-mail] inbox, it actually came from x who works at Snapchat. However, that is (in general), not how email works, for some reason (yes, I know, ancient protocol, tons of stakeholders, identity is hard, but come on...).

[josho]

I thought we had this through SPF. Ie. Your mail server can reject mail if the domain doesn't match spf records in dns.

Maybe it's time to start something like an SPF Everywhere campaign.

[lazaroclapp]

SPF Everywhere would be a start. But, as currently deployed, at least, SPF is nowhere near enough. I do research in security, and even I often have no clue, when faced with a new corporate email system, whether the email addresses I see can or can't be forged, depending on domain.

Hell, if I get [e-mail] on my Gmail inbox, I cannot really tell whether even the @company.com part has been authenticated or not. There isn't even an HTTPS like lock icon or anything, let alone a "Google has verified that this email comes from Amazon.com" assurance.

[r1ch]

SPF doesn't really do anything to prevent this. It can only protect the return path address, the scammer is free to use whatever From and Reply-To headers they like in the email itself - they don't really care if a bounce goes to the wrong place.

DMARC protects the From header, but isn't widely deployed.

[cm2187]

In fact in my experience 99% of users are unaware that anyone can post an email on behalf of someone else's email address, even users under 30.

[lazaroclapp]

Of course, because, well, unless you know the whole story of email, down to knowing what SMTP is, there is zero reason to expect that the from address of your email client lies to you. Which is also why all web traffic should be over TLS, because the same can be said of domain names. This is one area of security where our systems really should be made to match the user's expectation, and not the other way around. This is not a "grampa doesn't understand the interwebs" sort of issue, this is clearly broken design.

[darkr]

Non-envelope headers on emails are arbitrary. "From" (as opposed to Envelope-From) is one of these. Some mail clients looking at you, Outlook) just display the minimum amount of data including From, and make it non-obvious that this is not really where the mail was from. You only see this difference in address when you hit reply.

We had a phishing attack on an employee in accounting that was stopped in progress and just in time before a bank transfer took place. The emails in question passed SPF as they weren't actually from another user in our domain.

[tomjen3]

Adopt PGP signatures as a requirement on emails that include sensitive data. It should be easy enough to have an internal key server and a company key that counter signs all valid company keys. Require the key only be used for signing and kept on a usb stick.

[rkeene2]

S/MIME and X.509 is a lot more common than PGP signatures -- support for it is built in to most MUAs. Also, typically the keys are on smartcards rather than USB devices where the private key could be accessed.

[cyphar]

Or just buy everyone in your company a yubikey that is already set up and ready to go?