from Lenny Zeltser on Information Sec...
Businesses need a way to contact customers in a reliable manner that’s convenient for the recipient. Email is the obvious channel for such messages due to its ubiquity. However, this method presents many security challenges, as illustrated below. While it’s easy to highlight the vulnerabilities in these messages, it’s hard to offer constructive advice for a communications approach that strikes the right balance between security and ease-of-use.
Account Update Messages: Hilton and Delta
Consider the following email message that exhibited classic attributes of a phishing scam, even though it turned out to be a legitimate message sent by Hilton.
The premise of the message is identical to that of numerous fraudulent emails that arrive in people’s inboxes: Click the link to update your account information. Another, perhaps less significant issue with the message, is that its links are using HTTP, instead of HTTPS, which could expose the recipient to man-in-the-middle attacks.
Perhaps to help establish the message’s legitimacy, it included some details specific to the intended recipient: The person’s first name, Hilton HHonors membership tier and the number of the loyalty points. However, first names aren’t private and can easily obtained by miscreants; the membership tier can be guessed with a high degree of success; and the recipient is unlikely to know his or her number of points to be able to validate the message’s authenticity at a glance.
In fact, this email message looked so much like phishing, that even Hilton’s own support team on Twitter thought it was fraudulent:
When customers learn to receive legitimate messages that look like this, they lose the the opportunity to distinguish between real and fraudulent messages.
Here is another message that had similar issues and, as the result, looked very much like a phishing email. This one originated from Delta Airlines’ SkyBonus program:
Delta’s message included the recipient’s first name and SkyBonus ID, presumably to help the person establish authenticity of the email. Unfortunately, first names are almost public, and the recipient is unlikely to remember their ID without first looking it up. Also, the “View Account” link is using HTTP, not HTTPS. On the upside, the message gives the person instructions for accessing the appropriate account details without having to click the embedded link.
How would a customer be able to tell that this is a legitimate message from Delta? Non-technical people won’t right-click on the link and assess the URL’s legitimacy by its domain name or visit the link from a virtual machine and validate the site’s SSL certificate.
Transaction-Specific and Sparse: Vanguard
Unfortunately, the illustrations above tend to be the rule rather than the exception. I struggled to find an example of an email that, in my opinion, demonstrated a more secure approach. Fortunately, I came across the following message from Vanguard Voyager Services possessed many positive aspects:
It’s good that Vanguard’s message included a reference to the date of a recent transaction, which the recipient might have been able to remember and used to confirm that the email was probably legitimate. In addition, instead of embedding deep links, the message invited the person to visit the sender’s top-level site and explained how to navigate to the appropriate screen. This made it easier for the recipient take action in response to the message without clicking on any link in the email.
Unfortunately, the message included a link to vanguard.com and the link was using HTTP, not HTTPS. A more secure approach would have eliminated the link, leaving it up to the customer to locate the provider’s website; however, expecting the customer to locate the site via a search engine is not without risks.
Authenticated Sender: PayPal and Chase
For an arguably better example of a security-conscious email message, take a look at the following email from PayPal:
It’s good to see that this email lacked a prominent link for viewing transaction details. Instead, the person was instructed log into PayPal and review the information. There were also transaction-specific details that the recipient was likely to recognize.
Better yet, PayPal used the DMARC protocol to authenticate its sending server. This technique allows popular email clients, such as Gmail, to confirm the message’s origins. Protocols such as SPF, DMARC and DKIM make it easier to determine whether the message comes from a legitimate sender.
An example of a similarly-sparse and authenticated message came from Chase Card Services. This message was authenticated, avoided deep links, employed HTTPS and succinctly referred to a recent transaction.
Since the email client confirmed legitimacy of the PayPal and Chase messages above, recipients could feel more confident about clicking on the embedded links.
Characteristics of a Secure Customer Message
From a security purist’s perspective, a customer email should include the following characteristics:
- The message should avoid deep links
- It should come from a validated domain
- Any embedded links should employ HTTPS
If applicable, the message should refer to a recent transaction, but do so without revealing sensitive information. It should also briefly explain how to locate the desired portion of the sender’s website or app to view the corresponding transaction details or to take the expected action.
Instead of directly including a phone number, the message should encourage the customer to call the phone number they already have (e.g., back of the banking card) or tell the recipient to locate the information on the sender’s website.
In anticipation of customers’ attempts to locate the appropriate website portion or phone number via search engines, the sender should also validate that the site ranks highly on search engine results and register likely typo domains.
Balancing Security With Usability
Unfortunately, messages that exhibit the secure traits outlined above are not user-friendly. That’s a major problem from the business perspective and is probably the reason why most companies don’t send such emails. When deciding how to craft the message, organizations weigh the costs of user frustration and customer support against the expenses associated with phishing risks.
If the company bears the cost of customers succumbing to phishing scams, then ultimately it’s up to this firm to decide how to craft and send its messages. However, in many cases, individuals victimized by phishing scams are the ones stuck with long-term repercussions, for instance in identity theft scenarios. The company should account for not only its own direct risks, but also for the interests of its customers when deciding how to secure email-triggered interactions.
I am struggling to recommend a measure that would allow companies to strike the right balance between security and user-friendliness of its messages. At the very least, companies should avoid sending messages that resemble phishing on the basis of the “I know it when I see it” benchmark.
A more evolved approach would start with a minimalistic message that’s highly secure, then dial back some security attributes based on customer feedback. Be careful not to relax the characteristics too strongly; sometimes, non-technical users need to be protected even when they don’t realize it.
Updated August 2, 2016
Lenny Zeltser
