4 ms·

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

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 x@snapchat.com email in your y@snapchat.com 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 11y ago
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 11y ago
  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 bob@company.com 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 11y ago
  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.
darkr 11y ago
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 11y ago
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 11y ago
  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 11y ago
  Or just buy everyone in your company a yubikey that is already set up and ready to go?
cm2187 11y ago
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 11y ago
  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.

josho 11y ago

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 11y ago
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 bob@company.com 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 11y ago
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.

darkr 11y ago

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 11y ago

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 11y ago
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 11y ago
Or just buy everyone in your company a yubikey that is already set up and ready to go?

cm2187 11y ago

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 11y ago
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.