Simple two-factor authentication

I've been thinking a lot recently about information security and passwords. It's widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I've seen, short of client-side certificates, both require a trusted third party and provide little auditability.

I'm working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device ((iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons)) (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request.

So far, I've written a small Django server application, and a Python CLI device and client. They're not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I'll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator.

This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions.

On the other hand, I'm no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I'm going to release this (as I plan to once I get something working), I need a name. Ideas?

Fix bricked XOs automatically

I've been getting increasing numbers of requests from donors in the first OLPC Give 1 Get 1, many of whom are just getting around to opening their XOs, to have their laptops repaired. As is now widely known, due to a manufacturing glitch the first few batches of OLPC XO-1s that were shipped to consumers had a faulty motherboard battery holder. This alone wouldn't be a problem, if only two other things hadn't happened at the same time:

• The XO-1s were shipped with Open Firmware's security enabled. This caused them to have the same anti-theft protection as laptops deployed in the third world, without any of the benefits of a remote killswitch or tracking


• The XO-1s had a version of OFW which would fail to boot when the clock was below a certain value

The above two issues combined with the manufacturing fault was a recipe for disaster. Owners who discovered this in the first 30 days were able to get a RMA and a working laptop, but OLPC lacked the resources to support those outside of this minimal warranty. I've been running an OLPC repair center, OLPC DC Repair, (charging only minimal fees for labor and shipping) since mid-2008, and have handled dozens of these "unbricking" problems.

The procedure for repairing the above is straightforward and well documented. However, it can be tedious, especially for those who are unfamiliar with the tools involved. Since I needed the programming practice anyway, I decided to write a rudimentary Python script to automate the process.


Thus enters d6.py. d6.py makes it (hopefully) amazingly simple to unbrick your XO, so that you can get up and running as soon as possible. You can clone the git repo, or download it directly (permalink). To download and run in a single command:

python -c "import urllib2; exec urllib2.urlopen('http://dev.laptop.org/git/activities/olpc-contrib/tree/d6.py').read();

Plug in your OLPC Serial Adapter (or one of the compatible alternatives), and run the script as a user which has access to /dev/ttyUSB0 (or as root, not recommended) or change the path inside the script to something suitable to your system. This script is in the alpha state, is poorly documented, and may not handle all edge cases (read: other people's systems) well. I'm not responsible if it kills your cat, lights your XO on fire, or makes your wife leave you, but hopefully it'll be of some use. Expect a GUI shortly.

Limitations:

• Does not handle all error conditions


• No command line params


• Hard-coded path to serial adapter

Therefore, the code does not run on other platforms other than Linux. You might also encounter problems if you're running it on a system with brltty installed, removing it should fix the conflict.

Feedback is more than welcome in the comments.

I've been running an OLPC repair center