Security Nerditry

I came to find out this past week that one of my (very old, not terribly useful, don't get excited!) ssh private keys had been compromised in an automated attack against someone's computer that it happened to be stored upon.  While nothing even remotely interesting was compromised in this attack, it got me to thinking about my personal security situation - already being in this frame of mind from the Q2Q security framework hacking I'd been doing, I figured I'd give myself a full security audit.

I have accounts on 20 separate machines.  I have sudo on almost all of them, and passwordless sudo on 6.  Most of the passwords were the same, all-alpha, all lowercase password which could easily be guessed by scanning through text files related to my interests.  My authorized_keys was the same on most machines, contained about 5 or 6 public keys, some of which were available on other servers.  My home machine allowed logins using a different, but still easily guessable password.  Finally, all of the servers that didn't have an easily guessable password had a file called "password" in my home directory which I had, for some reason, never bothered to delete.  Its contents were what you might imagine.

Considering that some of these servers contain some pretty important data, I decided that I seriously needed a security upgrade ASAP.

Once I'd identified these problems, my plan to fix them was pretty simple.

• disallow password-based network logins from all machines that might ever have access to a private key
• You can do this by editing /etc/ssh/sshd_config and adding the line "ChallengeResponseAuthentication no"
  
• remove private keys from disks permanently attached to any machine
• pretty easy - copy them to a thumb drive, then delete using "wipe" (apt-cache show wipe)
  
• make sure that no two machines have the same password
• and that all my passwords were written down so that I didn't need to depend on memorization
• generate a new key that will never touch any media except the thumb drive and its solid-state backup media
  
• make sure that all machines only accept the new key and none that I am aware of accept any old keys
  
• set up a convenience mechanism for using removable storage to access all my crypto TLAs:
  
• SSH
• GPG
  
• Q2Q :-)

The solution ended up taking the form of a nice cheap Iomega thumb drive, which looks pretty stylish on my keychain.  Convenience was pretty important in solving this problem, because I regularly use 3 machines with 2 operating systems on each, and I needed a way to get at my code and my shell accounts from all of them.

I was pretty surprised by how easy the process was.  Ubuntu persistently mounts the disk using its volume label (I can't find anything that lets me change a FAT volume label in linux - does anyone know of one?) so I set it to "Fulcrum" under Windows and made a series of symlinks to /media/FULCRUM under linux.

• ~/.ssh/id_dsa points at my SSH private key
• ~/.gnupg points at a "gnupg" directory
• ~/.q2qcerts points at a q2q certificates directory on the keychain.

Under Linux, this doesn't even involve setting up ssh-agent.  I just made those symlinks, and now (thanks to the hilariously appropriate design of my USB hub) I have a login process worthy of a TV movie - I just sit down and "unlock" my remote accounts:

Under Cygwin, the procedure was much the same, symlinking to /cygdrive/f.  Under Windows itself, I lucked out - I wanted to use TortoiseSVN and WinSCP, which both use Plink, so all I have to do is run pageant, and tell it about my public keys each time.  I almost set up an autorun.inf to launch pageant with the appropriate command-line arguments, but drive letters are sadly not stable on Windows XP and it wasn't worth the extra effort there.

On OS X there is also some additional work.  Unlike Ubuntu, which appears to mount the USB thumb drive with the umask of 077 for the currently logged-in local user, OS X mounts it world read/write. OpenSSH is hard-coded to disallow an identity file that is writable by anyone but its owner, and there is no configuration to change it. Others suggest mounting a loopback volume from the thumb drive, of a filesystem type that does support permissions, but I don't need anything so drastic: luckily, Twisted's "conch" doesn't have such arbitrary limitations on security policy :).

In addition to upgrading the security of all of my accounts and data significantly, there are two interesting benefits of the physical aspects of this new security policy.  There is a tangible indication of when I'm working and when I'm not - if the key's not in the slot, I can't update SVN, and I can't log in to any work machines.  This makes an interesting ritual out of the "sit down to work" moment.  Also, I tend to lose my keys every so often, because I just drop them the moment I enter the apartment.  Now that I need them to use any of my computers, I imagine that will happen a lot less often.

I've also come up with a passwordless, client-agent-based authentication system for logins that I will eventually put into q2q which uses removable media like this as a native part of the auth protocol.  Any volunteers for an implementation, drop me a note. :)