Automated Fast Food Error Messages

Errors messages when ordering fast food at an airport? Have your error message Your Way! When I saw this blue screen of death, I had to try this novel payment system at Burger King. Sadly, the chain hired a cashier to sit next to the automated ordering system. She physically swiped the card and pressed the buttons for me. Hopefully in the future such intervention will not be necessary, but the machines must not be too robust. Windows.




Japan has already mastered the art of automated payment. There are some ramen restaurants where a customer would never even see eye-to-eye with a wait staff member. Here's an example from a ramen restaurant I tried in Fukuoka. Most restaurants have automated kiosks to order food.

Table-side Credit Card Readers

At Legal Seafoods in Washington Reagan Airport, I had my first experience with table-side credit cards in the USA.

Table-side credit card readers are popular in Europe. Instead of swiping a credit card at the counter, the customer is provided a self-contained unit at the table. The idea is to reduce fraud by wait staff (e.g., surreptitious extra swipes). But not all wait staff are comfortable with table-side units because of the culture of American dining. The user interface is clumsy. When wait staff add their own annotated buttons to a machine, you know that the user interface was not designed well. Read more about table-side credit cards from another blog.

Apple Time Machine Error Message

Hmm, what's wrong with this error message?

Crummy cookie authentication schemes

Ever wonder what happens after you log in with a password on a Web site like Blogger, Facebook, banks, shopping Web sites, and such? Often the Web server sets a cookie that essentially says, "Hi. This user already authenticated with a password, so don't bother to ask for the password when the user clicks on the next restricted Web page." This feature is incredibly convenient. Can you imagine typing your password each time you click on a different Web page? That would be unbelievably cumbersome.

Unfortunately, it's amazingly difficult to design a secure Web authentication scheme. Even the experts can mess up. Sometimes the flaws in a cookie authentication scheme can let an intruder bypass the password check entirely. In 2001, I published a USENIX Security paper that attempted to classify the flaws in various Web authentication schemes, discover the root causes of the flaws, and find ways to avoid the flaws. Yesterday, Steven J. Murdoch proposed a solution to fix a vulnerability he discovered in the Wordpress cookie authentication scheme. Further information appears in Murdock's paper and slides. The vulnerability permits an attacker to gain administrative access, and resulted from a type of "cryptographic splicing" flaw that was discussed in the USENIX Security paper and the more comprehensive technical report. Nearly seven years after these publications and the CACM Risks column, the same types of problems keep popping up.

Is there a perfect solution for secure Web authentication based on cookies? No, but we can learn from our mistakes. Designers of security-sensitive Web applications should read up on their history before repeating the mistakes of yore. Not everyone is a Steven J. Murdoch; Web application developers should rely on designs and code from folks like Murdoch rather than risking the design or implementation of a flawed scheme. But even then, be wary of putting too much faith in a cookie authentication scheme.

Open design of contactless payment systems

A year ago my research group showed that many contactless credit cards revealed personal information such as the credit card number, the card holder name, and the expiration date. We demonstrated how to wirelessly and undetectably read this information through wallets and clothing. If the credit cards did have security mechanisms in place, the mechanisms did not stop our attacks.

Now the credit card industry is "taking the same core functionality that's in the cards and embedding that in a mobile handset." While such systems hold great promise, I'm concerned because of the choral refrain of absolute claims, such as "if someone was to hack the transaction, it could never be duplicated." I would like to believe this. But where's the proof? Absence of proof is not proof of absence. If our systems relied on openly studied protocols, we could establish such proof.

Wireless communication does not have the luxury of physical security enjoyed by a closed network for payment processing. By definition, wireless communication is open and cannot be physically secured. Fortunately, engineers learn about the open design principle in introductory Computer Science and Electrical Engineering courses. The Information Assurance community already learned that openness of a sound design leads to stronger security. For instance, consumers rely on SSL to protect Web surfing at online banks. Thank goodness that the design of SSL is completely open and has been scrutinized publicly for over a decade. Quoting the undergraduate text of Saltzer and Kaashoek: "Violation of the open design principle has historically proven to almost always lead to flawed designs." The authors end with a warning that, "It is simply not realistic to maintain secrecy of any system that receives wide distribution." Let's hope that contactless mobile payments follow the open path for admiration rather than become yet another case study in computer security textbooks. In the meantime, look for wide-scale distribution of contactless payments in mobile phones.