People are the weakest link

laura
Best practices
July 17, 2017

All of the technical security in the world won’t fix the biggest security problem: people. Let’s face it, we are the weakest link. Adding more security doesn’t work, it only causes people to figure out ways to get around the security.

The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security. Don Norman

This isn’t news to anyone in the security space. Even those of us who are reasonably aware of security issues can still have problems. A few weeks ago I clicked on a phishing link. It was a delivery notification. I’d just ordered something online. It looked plausible. I clicked the link. Lucky for me there wasn’t drive-by malware on the site.
A few years ago, there were a number of email people arguing that two factor authentication (2FA) would fix the security problems. Steve wrote a couple blog posts here explaining why that was unlikely. (Defending against the hackers of 1995, What is Two Factor Authentication, Two Factor Authentication)

What is two factor authentication?

The older blog posts talk about 2FA, but a quick review for folks. 2FA requires two separate factors to identify a user. Many people describe this as “something you know and something you have.” A user might know their password and have access to a phone that will receive a SMS one time code. Many online services currently offer two factor authentication. Google even provides an authenticator app people can run on their cell phone. Companies that want to offer 2FA using that app can. I set up 2FA for a service over the weekend – it was as simple as taking a picture of a QR code and typing the resulting number into the website.

What’s the problem?

The problem is that it is possible to subvert 2FA. Back in 2011 attackers hacked one of the major 2FA vendors and stole the master keys. A little while later, some government contractors reported attempts to break in potentially using this information.
Now we’re using multiple forms of 2FA, so it’s more secure, right? No.
TechBeacon has a recent article looking at some of the ways that 2FA has been compromised. Most of these involve a human making a decision and taking an action to subvert security through different channels.
For me, one of the most interesting links is a blog post from Justin Williams earlier this month. His cellphone number was transferred, against corporate policy, to another phone. The hacker then used the 2FA to transfer money out of his PayPal account. This situation is why I cringe when I hear about a service rep bypassing policy to help out a user. Every time this turns out OK it’s great. But it’s also training customer support that it’s OK to make exceptions. No, it’s not. Even when it’s the saddest sob story you’ve ever heard.

Companies train users to be victims

Also this month a health insurance company sent a USB stick to users. The accompanying letter instructed users to plug the web key into their computer. No. Just No. This is training users to be victims when some attacker decides to do the same thing.
Marketers are another big part of the problem with training users to be victims. I wrote about this almost exactly a year ago in Working around email security. Steve walked through how many banks and retailers use cousin domains earlier this year. I saw another example just recently, prompting me to create a meme to share on Facebook.

Security and usability

For many years, there was a belief that security and usability were contradictory. Increasing security leads to less usability. There is certainly some of that in play still. But I think many of us in the email marketing space need to start thinking a little more about security. We are responsible for presenting our brand in the inbox world. Do we want to train our users that every email comes from a different domain? All the authentication and DMARC policies in the world won’t protect us from cousin domains. Marketers that use cousin domains are setting their brands and consumers up for failure.
A brand that is consistent in its sending and authentication not only develops good reputation for delivery, they also help innoculate users against attacks by third parties. Marketing departments can take the lead in creating a more secure environment online. Building security into messaging streams is more than just technical authentication, it’s about the whole message and domains and consistency. Every marketer needs to think about how they’re presenting their brand. How many different domains are you using in your marketing campaigns? How easy would it be for a bad guy to register a similar one?
Don’t set your users up for failure.

DMARC doesn't fix Phishing

Not a new thing, but a nice example just popped up in my inbox on my phone.

But FedEx solved their entire phishing problem when they published a strict p=reject DMARC record, right?
This didn’t come from fedex.com. It came from another domain that looks vaguely like fedex.com – what that domain is doesn’t matter, as the domain it’s sent from isn’t displayed to the user on my phone mail client. Nor is it displayed to the user by Mail.app on my desktop, unless you turn off Mail → Preferences … → Viewing → Use Smart Addresses.

That lookalike domain could pass SPF, it could be used as d= in DKIM signing, it could even be set up with DMARC p=reject. And the mail is pixel identical to real mail from fedex.com.
On my desktop client I can hover over the link and notice it looks suspicious – but it’s no more suspicious looking than a typical ESP link-tracking URL. And on mobile I don’t even get to do that.
SPF and DKIM and DMARC can temporarily inconvenience phishers to the extent that they have to change the domain they’re sending from, but it’ll have no effect on the vulnerability of most of your audience to being phished using your brand.

Happy New Year!

Well, we mostly survived 2016. A year ago I was making predictions about how 2016 would be the year of email security. I was thinking of things like TLS and authentication and access to the inbox. It wasn’t out of the question, Gmail said they’d be turning on p=reject sometime mid-year. They also were suggesting that they would be putting more value on messages that aligned, even in the absence of a DMARC signature. The first still hasn’t happened, and the second doesn’t appear to be in place, either.

That doesn’t mean email security wasn’t a hot topic in 2016. In fact, the use of a private email server was a major topic during the US elections. We also had spear-phishing play a major role in the compromise of campaign systems. I didn’t talk much about that here when it happened, but news reports make it clear that Chairman Podesta and others were targeted for compromise. The NY Times has a more in depth article with broader context around the attacks and how emails were used to infiltrate a major political party.
The irony is with all the time spent talking about how insecure the private server was, that server wasn’t compromised. Instead, the compromise was at Gmail.
We all need to pay attention to our email and how we use it. It also means when we’re sending bulk and marketing email we need to consider the private and personal information we’re putting in messages. Do you send PII? Is there a way you don’t have to? What can we do to protect our brand and our users?
It’s not just bulk email we need to think about, either. Personal email can contain PII, or personal information. A common saying among some of my security friends is “never put in email anything you wouldn’t want to see on the front page of the Washington Post or NY Times.” That’s an easy thing to say, but the convenience of email makes it easy to share information that we may not want on the front page of either paper. Many of us aren’t actually targets of malicious activity so we don’t have to worry about being targeted the way elected and other officials are. But that doesn’t mean we are not at risk. It just means we’re at less risk than others.
Email is a frequent vector for malicious actors to access computers. Most, if not all of the major breeches in the last few years have started with a phishing attack of some sort. The attacks are planned out and sophisticated. This is not going to get better. The phishers are smart and plan the attacks. We also need to be more personally aware of security given the current political climate. We need to take steps to protect ourselves more than we have in the past.
Security is more important than ever and we all need to protect ourselves.

ARC: Authenticated Received Chain

On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.
What breaks?

DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.
This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)