Phillip Hallam-Baker's Web Security Blog

"How about a fun post relating the price of gas to online shopping?" Its an interesting question, but I cannot promise the answer to be much fun.

Rising gas prices have been a source of some concern for people here in the US. When I first moved to the US in 1995 the price of gas was under $1 a gallon. Today it is close to $4. While that is still much less than I was paying 20 odd years ago in the UK it is a significant rise and even if the recent supply restrictions or weakness of the dollar were to reverse there is little reason to believe that the long term trend will follow.

As the Western lifestyle spreads, so do Western patterns of consumption. That means greater demand for energy, in particular oil and greater demand for resource intensive food, in particular meat and high water demand crops such as wheat. As Gandhi once observed, it took the resources of half the world to support the British Empire at its peak, how many worlds would India require to achieve the same standard of living?

To date the Web has quite definitely been a contributing factor in the energy crisis. In addition to the significant quantities of energy require to run the Internet infrastructure itself, Web content is evangelizing the adoption of the high consumption Western lifestyle at breakneck pace. And just as the short term impact of the electronic office was to cause an increase in demand for paper as more documents were produced and printed out, remote collaboration technologies such as the Web, email and voice conferencing appear to be driving increased demand for long distance travel rather than reducing it.

But before we get too desperate, there is also reason for optimism. Although the electronic office did increase demand for paper short term, my friend who analyzes such things tells me that the demand for paper has been sharply reducing in recent years. In particular demand for newsprint is plummeting. This is certainly consistent with my own experience, I used to buy at least one newspaper paper a day, today I only ever buy a paper at an airport to read on a plane.

I expect the longer term effect of the Web will be similar. In the short term online shopping probably increases net energy consumption per product delivered. But as scale increases and the efficiency of the entire supply chain is improved over time the energy input per unit delivered should begin to drop. Five years ago very few people were talking about energy cost or availability in building large data centers. Today it ranks ahead of staffing. It is easier (and cheaper) to take the employees to the cost efficient energy supply than vice-versa.

It seems to be a law of nature that things have to get worse to get better. Eventually we will have high quality electronic books that are better than paper and high quality teleconferencing that is better than meeting in person. We are not quite there today, but there is no reason we cannotget there in the very near future.

Posted by Phillip Hallam-Baker at 11:27 AM | Permalink | Comments (0) | TrackBacks (0)

Security Dr Seuss style (via Bruce)

On the serious side, it does appear that there might be some 'acceptability' issues. But considering some of the 'security' solutions that have been inflicted on unwilling users it is hardly beyond imagination.

Posted by Phillip Hallam-Baker at 06:39 PM | Permalink | Comments (0) | TrackBacks (0)

We have all done it: we fill in a form on a Web site, we click OK and the Web site trashes all the information we just spent up to an hour working on.

Why do Web sites think that this is OK? This week I have filled in several web forms that required lengthy chunks of descriptive text that for some reason thought it was ok to just trash all my effort and repeat it because something was not exactly right.

Web browsers have remembered passwords for years. We have history files. But none of the major browsers can be configured to automatically keep track of all form data as it is entered. There is a Firefox form saver that allows you to elect to save a page and somewhat interestingly an experimental project that has been started by Ka-Ping Yee who folk in the security usability community know from his principles of usability.

Not trashing user effort should be considered a key usability requirement. But besides that I would like to have a permanent record of every form that I have entered at every site in a verifiable archive. While there might be people who would not want their activities to be tracked at certain sites this is already an issue with the history mechanism and something that can and should be fixed in any case. There should be a button that you can click to tell the browser not to track or record any interactions at that site.

Posted by Phillip Hallam-Baker at 07:45 AM | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by Phillip Hallam-Baker at 05:36 AM | Permalink | Comments (0) | TrackBacks (0)

Some people have asked why I did not mention
john Markof's article on the email phishing scam where a fake subpoena was sent to executives of certain companies.

The answer is that I actually wrote the entry on Monday before the attack occurred and the scheduling robot posted it.

This particular attack appears to have originated from a group that specializes in bank fraud against company accounts. But now that the possibilities of this particular vector have become apparent we will probably start to see similar attacks with a corporate espionage motive.

Posted by Phillip Hallam-Baker at 09:07 AM | Permalink | Comments (0) | TrackBacks (0)

With RSA over, its back to thinking about security usability and in particular email security usability. When I wrote the dotCrime Manifesto, I began by saying that there is more to security than just cryptography. Then I described a proposal for making email more usable that was essentially pure cryptography, albeit cryptography that was much better hidden than in the past.

The value of applying the task based analysis is that it has exposed a number of security issues that have absolutely nothing to do with cryptography and lead to far more real world problems than actual cryptanalytic attacks do today.

One thing I discovered when working on the task analysis is that it is pretty hard to do by thinking about it. I remain skeptical as to the value of small-n studies in the evaluation of the design itself, but I do think that they are likely to prove useful in building up the set of tasks.

So here are the tasks that I performed with email yesterday:

• Sent a mail message to a company employee.
  
• Read a company email about an organization issue.
  
• 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 be.
  

I suspect that these are pretty typical. But as I will discuss in the next installment, the current email clients do not give me sufficient information to complete these tasks securely without the user engaging in an unreasonable degree of effort.

Posted by Phillip Hallam-Baker at 05:20 AM | Permalink | Comments (0) | TrackBacks (0)

During RSA I was using Twitter at the request of the organizers of the blogger event. Outside conferences twitter seems to me to be the most monumental time sink I can imagine. I have turned it off on my work machines.

Twitter is essentially a variation on IRC or Jabber that can be forwarded over SMS. The cell phone thing seems to me to be a step too far. Each user has a log to which they post 'tweets' of up to 140 characters to. People can follow other people's twitter logs. A suprising number of logs consist of 'what is the purpose of twitter'. Its one of those zen things I suppose.

So now Andrew Baron is auctioning off his Twitter handle on Ebay, which has raised many blogger's eyebrows including Chris Brogan who asked whether someone is going to buy it. Brogan asks the wrong question of course, the bid price is already $1520 and it is arguably a lot more valuable than a Hail Mary cheese toastie. But what he is really pointing out is that his 1600 followers can melt away rather quickly.

At close to $1 per follower, the handle is certainly highly priced even by dotcom standards. There might be 1600 eyeballs but I can't imagine that many of them would stay long if there was an attempt to monetize them by spamming them with Viagra ads. And while 1600 followers is quite a lot on Twitter, it is hardly enough to bootstrap some other project.

Posted by Phillip Hallam-Baker at 10:16 AM | Permalink | Comments (0) | TrackBacks (0)

While I am in the San Francisco Mosconne, the protest against the Olympic torch relay is being synchronized using a twitter feed.

People have a way of applying new technologies in interesting and unanticipated ways.

Posted by Phillip Hallam-Baker at 03:20 PM | Permalink | Comments (0) | TrackBacks (0)

CNN

Posted by Phillip Hallam-Baker at 03:15 PM | Permalink | Comments (0) | TrackBacks (0)

Whitfield Diffie kicks off and urges us to be cautious of the claims that imminent cyberwarfare requires us to surrender civil society. We cannot meet these threats through cryptography alone

Marty Hellman, warns us about complacency, in particular the fact that humans are very bad at estimating the risk of low probability events. He is currently working on nuclear deterence.

Ron Rivest, re-interprets the Turing test in terms of cryptography. Interesting. He will be entering the NIST contest with an MD6. Also voting, cryptography is relevant to provide end to end security. Has a paper coming with David Chaum. Also on the standards body for setting acceptance criteria for voting machines.

Systems to be software independent. A system is software dependent if a bug or defect can cause the outcome to be affected. So the counter to this is a paper trail or whatever. He would like people in the room to comment on the necessity of this to the Electoral System Commission.

Shamir, progress in breaking SHA-1. The complexity is now 2^60 which is within reach of a distributed crack program. There is a group trying to do this but they have only a few % of the necessary computing power.

Intel has announced it is to put AES in hardware on their cpus from 2009. There will be 4 instructions for doing this. [hey this will make cracker's more efficient as well!] Mention of the bypassing of disk encryption by rebooting with a different O/S and looking at the memory. Will be good to see the end of encryption in software.

On Blu-Ray vs HD-DVD. a rumor Warner might have tipped to Blu Ray because the system has a means of introducing a new security system after the original one was cracked. So maybe security caused the tipping function.

Burt: How about software independent cyber security. Rivest, hard, Whitt need an existence proof, had one for voting for millennia.

Burt: How can we predict the probability of algorithm failure? Marty, we tend to treat cryptography as a Maginot line, algorithm security not the issue. Mentions Kocher's side channel attacks. Need to have a plan-B, what happens with your breaking of a 128-bit system?

Shamir, points out that main losses are very large losses from high level attacks and from very low level attacks. But the media tends to concentrate on the middle attacks that are not very common. Need to focus on stopping the low and the middle, not get distracted by the rare high level attack.

Burt: who has the capability to act, people, government. Whitt, lots of people talk about security education, comes from an era when people were told about security process. Mcrosoft correctly deduced that first to market was more important than security. Points out that Sun has a chip with the whole of Suite B implemented. Shamir, Intel sells more CPUs than sun, Whitt whose execute more CPU cycles per sec at the major Web sites. Need to have a design and development strategy that is transparent and tells us that something does what it claims without anything hidden. Rivest, Ken Thompson, what if the Intel chip keeps a copy of your AES key...

Continue reading "RSA Cryptographer's Panel" »

Posted by Phillip Hallam-Baker at 10:42 AM | Permalink | Comments (0) | TrackBacks (0)