Trusting Trust and JavaScript

About 2 years ago, I tried to come up with a way to make OpenID and similarly single-sign-on systems less phishing-prone. That turned into BeamAuth (note to self: must publish the source code! Argg, so little time.) Minutes before I presented BeamAuth at CCS, Adam and Collin cornered me and found a subtle but significant weakness in BeamAuth. Those two are crazy smart, how could I not befriend them?

Adam and Collin spent some time trying to figure out if they could extend BeamAuth into BeamAuthlet, basically BeamAuth with some JavaScript sprinkled in to make it more powerful. In the process, they uncovered a half-dozen ways to subvert JavaScript when you control the environment (i.e. the URL you’re at). So we all set out to find JavaScript-bookmark-based tools that were vulnerable, and we found 6. We recommend a simple fix, which most have implemented. The paper’s in submission, but MIT’s Tech Review’s already reporting the news.

Very well covered by Tech Review, no complaints! Well, except maybe for my line about “life insurance”, but that’s my fault, I didn’t explain that well. What I meant is that security is medical insurance for 20-somethings: nobody thinks they need it until they’ve got a broken arm, and you often hear “well, nothing’s happened so far, right, so I didn’t need the insurance anyways.” So I don’t like the argument that “this bug probably hasn’t been exploited,” because that argument can be used against just about every security bug discovered. The point is to catch the bug before it does significant damage. You know, get the insurance before you have an accident. But anyways, bygones.

Two small corrections:

• “Adida and his team”: Collin and Adam aren’t “my team,” they’re web security colleagues, and we happen to work together on this one paper. Hopefully we’ll work together on more stuff.
• the company who didn’t fix the bug … actually they had fixed it before we came along, but then their users complained because, in their specific case, fixing the bug required reducing functionality, and users preferred the security risk to the lack of functionality.