People are the weakest link

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.

Related Posts

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.)

Read More

You're kidding me

All the authentication and DMARC in the world can’t save you from stupid.
I just got a survey request from my bank. Or, at least, it claimed to be from my bank.

Read More

Beware the oversimplification

stencil.linkedin-post-7
Setting up a DMARC record is the easy bit. Anyone can publish a record in DNS that will trigger reports to them. The challenge is what to do with those reports and now to manage them.
DMARC is a complex protocol. It builds on two other protocols, each with their own nuances and implementation issues. I’ve written in the past about what DMARC is, what you need to know to decide if you’re ready for DMARC and walking through whether or not you should publish DMARC. I’ve done talks where it’s taken me 20 minutes and dozens of slides to set up the context for explaining DMARC. Even experienced email folks can have moments where we get confused by some of the nuances.
DMARC is not a passive protocol. DMARC is an active protocol. Even with a p=none record, there is ongoing monitoring and work. Why consume reports if you’re not going to monitor them? The reports are there so that senders can monitor their authentication. If you’re not monitoring, then why waste cycles and bandwidth to receive them? Do you even know if your mail aligns? Can your mail server handle emails with attachments larger than 10MB? Does your mail server block .zip files? All of these things can cause your mail to be rejected and you won’t receive reports.
Postmark has a great post on DMARC and even has some examples of reports.
I know, I know, there’s a lot of fear mongering about how any company not publishing DMARC isn’t going to get to the inbox. We’re not there, yet. We likely won’t be there in the next few years. We may never get there. In any case, it’s much better to actually think about what you’re going to do with DMARC Plus, ISPs are already checking for DMARC style alignment even in the absence of a DMARC record. You don’t have to publish DMARC for this to happen, it already does.
I’ve said it before: publishing a DMARC record is a good idea. But every company needs to take minimal steps to figure out if publishing DMARC, even just to receive aggregate reports, is the right thing for them. It’s not right for every company or domain at the moment.

Read More