According to the Tech Review article, Delfigo looks at the pattern of how you type your password into the web form with some JavaScript code. I’m guessing this means timing of keystrokes, number of times the delete key is used, etc.. Funny, I implemented a very basic prototype of this kind of typing-pattern recognition as a class project based on an idea I’d heard about in some tech magazine…. that was back in 1998/1999, and I wasn’t using JavaScript, which didn’t really allow for this fancy pattern detection yet. Oh, and it was really really crummy and prototypical. But I digress.

Now, if typing pattern detection is all there is to Delfigo’s technology, then it may well be very cool but it may not be particularly useful: it’s easy for me to put up a fake site that tricks the user into typing his password and measures exactly the same things that Delfigo measures, maybe even by simply copying Delfigo’s JavaScript (which I can easily get since it’s downloaded to my browser). After that, I can pass on the password and the extra measurements to the authentication server. In other words, it sounds just as phishable as a password. Now, if Delfigo is doing additional things, like checking where you’re logging in from, and looking for patterns there, then that’s interesting and potentially useful from a security point of view. But the keyboard typing pattern detection won’t serve a real security purpose other than making it a little bit more complicated to phish, and thus potentially redirecting attackers’ efforts to other sites… until Delfigo-protected sites become numerous and valuable enough to attack, of course.

And yet, no one knows the results. Not me, the creator of the system. Not the team in Belgium who implemented, deployed the system, and oversaw the generation the cryptographic keys. We all have access to the raw data, but until the trustees arrive in a few days to jointly decrypt the tally, we won’t know the result.

The result is there, embedded in the numbers, we just can’t see it yet.

Isn’t cryptography magically beautiful?

UPDATE: The Harvard Press Release.

UPDATE 2: The UCL Press Release.

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.

Richard has graciously agreed to release my segment on Open-Audit Elections under a Creative Commons license. Here it is, and I have to say that Richard has done a fantastic job of capturing the essence of open-audit voting. I only wish he’d given Andy Neff a bit more camera time, since Andy really knows how to capture some of the interesting complexity of the issue.

Voting with cryptography is not about making your vote more secret. It’s about making your vote more verifiable. For those who advocate traditional paper ballots, the point is that open-audit elections are significantly more verifiable. There’s a reason for the extra complexity, promised.

But since I spent 3 hours talking to Cyrus, the reporter, I blame myself as much as anyone for not getting that important point across.

Cryptographic voting schemes like Scratch & Vote offer a far superior method of verification: you the voter, can check directly that your vote made it into the tally unharmed, and that the votes of all other participants were tallied correctly. Directly, not by trusting an election official. All while preserving the anonymity of your vote, of course. Sounds impossible? Intrigued? Go check out my lecture on cryptographic voting.

(No scientific paper floats in the vast ether of knowledge on its own. My work is based on the ground-breaking work of David Chaum, in particular Punchscan.)

UPDATE – best reader comment already in: “I suggest a scratch and sniff feature be included so that we can determine whether or not a candidate or measure stinks.”

UPDATE 2 – It turns out, the Onion beat me to the punch.