Emai security usability continued.
We tend to think about the basic email operations as sending and receiving messages. From a security point of view however there is a problematic third category, the reply. In the last installment I had three reply tasks:
- Replied to a mail message purportedly sent by a company employee.
- Replied to the company employees only on a message sent to company employees and a partner.
- Replied to a query from a customer that had been forwarded to me to both the originator and the customer.
The problem with reply is that it it consists of (1) receiving a message, (2) generating a reply based on the message received. If the person making the reply makes a false assumption as to the origin of the original email the reply is likely to be one that was not intended.
Lets take the first example, replying to a message that purports to come from a company employee. Like any large organization, there are a large number of employees who do not know each other directly. And due to my job function, there are many people who contact me shortly after we make an acquisition. So quite often I will receive a message from someone who is (or considers themselves to be) quite senior who I have no direct knowledge of, asking me for information that could be commercially sensitive.
Current email clients do not meet the requirements of the first law 'sufficient information'. There is no way for me to know who sent the message with any degree of certainty. Anyone can forge a From header.
The problem for the new hire is even worse. As Shizzy demonstrated when he yanked the chain of a new Starbucks hire for several weeks while pretending to be the CEO. There is no way for a new hire to know that all internal mail comes from the starbucks.com domain and that they should consider messages from the starbucks-inc.com domain to be fraudulent.
And Outlook makes the problem even worse by hiding the DNS email addresses from the user completely so they don't know the address they are responding to. The reason for this remarkable design choice is that Outlook was originally designed as an X.400 mail client and X.400 mail addresses are inordinately long so displaying them to the user would take up a lot of screen real-estate. Outlook is not the only desktop mail client to do this, but it is the only one I have used that does not provide the option to display the full RFC821 email address.
So when replying to an email we are replying blind. The only information we have in the display is information that is untrustworthy. The only information that is trustworthy is the DNS based RFC822 email address which is at best subject to a look alike attack, if not hidden completely.
All three tasks suffer as a result of this information deficiency in ways that can easily lead to an attack, or worse, result in an inadvertent user error. Why is an inadvertent error worse than an attack? Because people make mistakes of their own accord far more often than someone attacks them. Since the 1950s there have been no significant terrorist attacks that have succeeded against nuclear power stations but there have been many incidents caused by operator error. As Ira Winkler keeps pointing out, the fact that a disaster occurred through a design flaw rather than an attack does not make it any better.
So what can go wrong?
- Replying to company message: User may reply to a social engineering attack.
- Replying to only company employees on a crossposted message: User may not identify the company employees correctly and the reply intended to be internal only is sent to the partner
- Replying to a thread that has been forwarded internally: The response sent out to the customer may contain internal conversations in the thread that were intended to be kept confidential.
I first saw an example of the last one when I sent a note to the original security architect at Netscape in 1994, pointing out that there was a problem with his approach to random number generation. In short, a pseudo-random number generator that only has 32 bits of ergodicity in the input cannot generate more that 32 bit of ergodicity in the output regardless of the number of bits the algorithm generates.
Various Netscape employees commented on the message in particular and the Web development taking place at CERN in uncomplimentary terms on an internal thread, all of which I received when the security architect forwarded his authorized reply. If I had circulated the message further it would have caused considerable damage to the relationship between Netscape (at that time a very small startup) and what became W3C.
The common thread in all these cases is that the user does not have the information necessary to complete the task securely in a trustworthy form. Worse still, the user is presented with untrustworthy information.
