08 December 2010

Simple two-factor authentication

Do you want to allow "Rebooting of Cluster 19" as Jane Doe, Foo Corp? Yes/NoI'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?

11 October 2010

Key transition

As Christian mentioned, the Debian Keyring Maintainers did a "promote" this weekend of the new keyring. I figure it's an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring.

For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian's.

If you signed my previous key, you should sign the new one unless you're feeling extra paranoid today.

31 August 2010

Generating manpages with help2man

To quote the ftp-masters REJECT-FAQ :

  • Write manpages. Yes. Really. Write them. Well. It's basically: If your program/tool has a help and version commandline option you can simply run help2man and have a working start.

What may not be obvious to the recently REJECTed developer is actually how to use help2man. To try t0 explain the process a bit more verbosely, I took the liberty of writing a tutorial on the Debian wiki. Comments and corrections are welcome.

Of course, help2man-generated manpages are no substitute for real, hand-written manpages made of sweat, blood, and the Maintainer's tears, and it won't work for all packages. This is just a start, and is much better than no manpages at all.

There was a discussion on #debian-devel a couple of days ago when I brought up my creation of the above, and some wondered if it wouldn't be better to add hooks to man-db to allow package maintainers to enable manpage generation at runtime. I'm not sure if that idea will ever make it into a proposal, but, if the details of the implementation were worked out, would be much better than the above, manually generated method.

25 June 2010

Hello, (Planet Debian readers of the) world!

I'm a Debian Maintainer currently undergoing the New Maintainer process. I'm also an Ubuntu MOTU as of recently. I have several packages in a variety of categories, but I specialize in Python-based software.

I'm interested in exploring more ways to improve cross-distribution coordination, specifically as it relates to the Debian Sugar packages. I'm working to get all of the Ubuntu-specific Sugar packages included in Debian, which will probably be a summer-long effort.

22 June 2010

Post-mortem on WMF Server Donation

Of the 12 servers sent to Sugar Labs, 6 arrived at the Arlington Career Center. Three of them stayed there, whereas I brought three home to attempt to salvage what I could from them. The three that arrived are described below.

wmf-01 "le premier"

2x Dual Core AMD Opteron(tm) Processor 285 @ 2606.342 MHz
2x 250 GB HDDs, 2x slots empty
2 Gigabit Ethernet NICs

This machine worked swimmingly.

wmf-02 "something witty"

2x Dual Core AMD Opteron(tm) Processor 265 @ 1800.000 MHz
2x 250 GB HDDs, 2x slots empty
2 Gigabit Ethernet NICs

This machine was incredibly noisy when turned on.

wmf-03 "lemon"

2x Dual Core AMD Opteron(tm) Processor 265 @ 1800.000 MHz
2x 250 GB HDDs, 2x slots empty
2 Gigabit Ethernet NICs

This machine did not fully POST, and was incredibly noisy when turned on.

Between them, only one of them had working fans. The other two made ungodly noises. We managed to salvage enough fans from the machine that didn't post so that we now have two working machines cooling-wise.

We hope to install these machines at a Virginia co-lo center after we finish getting all the parts for Ivan Krstić's blackrock.

NB: This post has been sitting around in my drafts for a while, and I just got around to posting it now. We're still waiting on some last-minute parts before putting these servers into production.

16 June 2010

If I had a dollar for every idea...

On suspendable computers retaining network services with conditional wakeup...

(11:28:29 AM) Luke Faraone: don't you hate it when you think of something cool, only to find that someone else already thought of it?
(11:28:47 AM) Peter Harkins: Depends. Sometimes I then think "Awesome, now I don't have to spend all that time building it."
(11:29:34 AM) Luke Faraone: I recently was thinking "it'd be cool to be able to have a smaller 'little computer' with a NIC, some RAM, and a low-powered CPU to maintain presence on IRC etc when my computer's sleeping." Then I saw http://it.slashdot.org/story/10/06/13/0641228/Microsofts-Sleep-Proxy-Lowers-PC-Energy-Use
(11:29:39 AM) Luke Faraone: ... and it's from MSFT.
(11:30:12 AM) Peter Harkins: cute
(11:30:25 AM) Peter Harkins: There are lots of tiny Linux pc's out there, though.
(11:30:45 AM) Peter Harkins: I've seen a couple the size of a power brick - you plug them in, add ethernet, done.
(11:31:14 AM) Luke Faraone: what'd be really cool is if one could author an API that would allow for desktop applications to request access to run services on the device, and have state magically transfer across them.
(11:31:40 AM) Peter Harkins: I've seen people talking about doing that - I wouldn't be surprised to see it commonly in 5y.
(11:31:49 AM) Peter Harkins: It's sort of the logical extension of GNU screen.
(11:32:10 AM) Luke Faraone: we have live migration of VMs in the enterprise market.
(11:32:34 AM) Luke Faraone: if the wall wart had hypervisor support, you could just operate each service in a sort of sandbox.

I know that in order to make it work in reality, we'd need support from app developers, but are there any technical reasons this won't work?

25 February 2010

Low-tech anti-surveillance tool for the OLPC XO-1

After reading several articles about the alleged spying that was enabled by a Pennsylvania school district via its one-to-one MacBook, and seeing discussion on a variety of mailing lists, I've decided to implement my own zero-cost, no-hassle solution to the problem for the OLPC XO-1's camera.

This should be able to be adopted in deployments everywhere, by anyone with a piece of paper, or anything else they can slide through the plastic faceplate.

Just say no to fancy addons and factory-added "shutters" or "covers", make your own!

14 January 2010

Sometimes things get complicated... (Handling upgrades from Karmic)

I'm the package maintainer for Autokey in Debian. Upstream recently changed from using GTK+ to Qt4, which caused more than one complaint from users of testing.

The GTK+ version of the package is published in Ubuntu 9.10 Karmic. While upstream is continuing to do regular releases of the GTK version, they are focusing on the KDE version and have changed autokey to refer to the KDE version, while renaming the GTK version (formally autokey) to autokey-gtk. To make matters worse, upstream releases both as separate tarballs, and the packages conflict with one another.  (due to technical limitations)

What's the proper proceedure for handling this in Ubuntu? Should -gtk conflict with autokey, replace it, with autokey-qt being available as an option, or should I just keep things as they are and have the package "change out from under" users when they upgrade?