Live data from Hacker News

Snapchat Employee Data Leaks Out Following Phishing Attack

techcrunch.com

61–62 of 62 posts

Re: Snapchat Employee Data Leaks Out Following Phishing Attack

#61
post #60

Earlier quoted context omitted.

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 c…

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.

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.

Re: Snapchat Employee Data Leaks Out Following Phishing Attack

#62
post #43

Earlier quoted context omitted.

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 c…

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.

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.

Post reply on HN