Bits of humor

For posterity's sake from an architecture course I used to teach. Could be a double post.

Personal questions for authentication, a misguided approach

The federal government might want to read the advice from Stuart Schechter et al. published in the IEEE Symposium on Security and Privacy about why to avoid "Golden Questions."

A screenshot of the E-QIP website.

Cheers for a pint of Wifi

Apple Updates

The biggest update ever from Apple is being downloaded.

Software and the IOM Report on the 510(k) Clearance Process as a Word Cloud

Yesterday the Institute of Medicine released its report on
Medical Devices and the Public's Health: The FDA 510(k) Clearance Process at 35 Years. The report drew a number of strong reactions.

• Study Faults Approval Process for Medical Devices
  by BARRY MEIER, The New York Times, Published: July 29, 2011


• Study of Medical Device Rules Is Attacked, Unseen
  by BARRY MEIER, The New York Times, Published: July 27, 2011


• HeartWire has also weighed in.

For more information about the role of software in medical devices in the context of the 510(k) process, see my IOM webcast, the IOM report on Trustworthy Medical Device Software, and publications on the SPQR Lab website. The PDFs are free at the IOM, but there's a clumsy registration process through which one must first wade.

I decided to run the IOM report through Wordle to visualize topics of emphasis. I removed most of the header information before processing. Look below if you want a PDF of higher quality.

The future of medical device interoperability and mHealth

mHealth Today.

mHealth Tomorrow.

iPhone software update for security

They say the devil's in the details. For software updates, it's literally true.

It's Hard to Build a Web Site Secure Against Untrusted User Input

Recently it was reported that a group of hackers broke into Citibank. One security expert was quoted saying, "It would have been hard to prepare for this type of vulnerability." Maybe so, but the problems are hardly new if this part is true:

They simply logged on to the part of the group's site reserved for credit card customers - and substituted their account numbers which appeared in the browser's address bar with other numbers.

I'm sure someone else has stumbled onto this problem several times (it would be hard not to because there are so many websites with sequential numbers and unauthenticated data in user input fields), but I know of at least two research projects that looked into the technical issues behind such vulnerabilities.

Prof. Nickolai Zeldovich at MIT innovated the RESIN research project to help web application developers more clearly specify assertions that pertain to security. For example, a common web application error is forgetting to include an authentication check. Pretty simple error, but pervasive and cumbersome to prevent without a way to express such assertions. The RESIN language helps programmers control information flow.

A second project is my own, so I am more familiar with it. Back in 2001 (when we said "web site" rather than "website"), our small team analyzed the authentication mechanisms in several websites. It was hard not to find problems where websites were susceptible to impersonation of the user. Relevant to the Citibank incident, there were cases where websites assumed the user would not change certain elements of the query string or HTTP POST request. Embedded in these requests were sequential identifiers. Here's one example from a talk several years ago:




After prodding from people working on web application toolkits, I took a new look at web authentication in 2004. Alas, even the web toolkits had authentication flaws. In one product used by large chain retailers, it was possible for a would-be thief to impersonate others to download retail receipts by changing hidden HTML code. I wonder if this problem is similar to the flaw at Citibank. This work was never published, but did appear in the WSJ.

For more information, I encourage the interested reader to consume these documents:

• Dos and Don'ts of Client Authentication on the Web from USENIX Security 2001 [PDF and slides from a series of talks]


• Inside risks, web cookies: Not just a privacy risk 2001


• Book: Exploiting Software 2004 (see the section on "the user input problem")


• Biggest Web Problem Isn't About Privacy, It's Sloppy Security 2004


• More Scary Tales Involving Big Holes In Web-Site Security 2004


• Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Applications from USENIX Security 2009 [PDF]


• RESIN from SOSP 2009

There are probably other historical technical documents of relevance from OWASP or the RISKS Digest. Happy searching!