Wednesday, February 22, 2006

Managing passwords and keys

Once upon a time I used a single password everywhere except on few, few exceptions (my system account or SSH key, for example). After some time I realized that that wasn't very clever because a break-in in any of my online accounts could open them all for attack. Not to mention that this was also problematic due to different sites having different password policies and having different trust levels: you surely do not want to share the same password between your mailing list subscriptions — which very often travels in plain text form — and your GPG passphrase!

Since then I have been using a unique complex password for each account... which has turned up to be a more-or-less unmanageable approach given the number of accounts I have. To make this approach less painful, I wrote all the passwords in a GPG-ciphered text file. I then created a pair of dirty scripts to view and edit that safe file, but I have to confess that they are very ugly and are currently broken for a number of reasons. Also, keeping that file on the hard disk was not something I was very keen on; yes, I have a backup, but it is sooo outdated...

However, using such simple ciphered file has its advantages. I can trivially access it from any OS, I do not rely on any password manager utility and I do not need to trust its code to not disclose information. So what have I done?

I've created a little shell script that allows me to consult and modify the passwords database easily; yes, simply put, it is "yet another password manager". However, and as I wouldn't like at all to lose my private SSH/GPG keys, the "secret" database also serves as a repository for these keys.

The idea is to keep all this critical, non-recoverable data in a central place, making backups trivial. For example, I'm planning to stick the script alongside with this sensible data in a little pen drive (or floppy disk) so that it can be stored in a safe place. This way, I will not have that data in the hard disk: it will only be available when I really need it by plugging the pen drive and simply executing the script within it.

Consider the following:
$ mount /safestore
$ /safestore/safestore query some-site
... enter your GPG passphrase ...
... your user-name/password is shown ...
$ unmount /safestore
The above commands could be used to request the user-name and password for some-site.

Or this (assuming the disk is already mounted):
$ /safestore/safestore sync
Which could synchronize the GPG database in the home directory with the one in the external drive.

And what about creating a SSH key and installing it on your home directory?
$ /safestore/safestore ssh-keygen
... answer some questions ...
$ /safestore/safestore ssh-keyinstall key-name
Of course, losing that pen drive could be a very serious issue... but you already have a backup copy of your keys somewhere, right? Also, if the GPG key has a strong passphrase and considering that someone had interest to crack it, you'd have enough time to regenerate your keys, revoke the old ones and update your passwords before he'd get any data out of the ciphered drive.

I'm curious to know how people manages this stuff themselves. At the moment I am not planning to publish the script because it is very customized to my needs but I may easily change my mind if there is interest in it.

6 comments:

Anonymous said...

PKI, the public-private key separation is good. Its mathematically sound. So finding ways to use it, and then finding ways to manage the PRIVATE key part in a secure fashion is what we're all doing.

NetBSD is weak (at the moment) in support for the USB based key tokens, smartcards. Most of the key development (sorry) seems to be happening in other OS. If this was resolved, then the problem simplifies massively: store your private keys on physical media which you guard as well as your door pass, your VISA card. Have the computer detect when it is removed from the machine (hotplug USB support required)

This works for SSH, for X.509 certs on the web, for Kerberos (GSSAPI).

These tokens, like the rainbow iKey are as small as, or smaller than USB memory sticks. They are batteryless, have a very long duty cycle.

There are more complex solutions using things like SecureID, but you are then in a replacement cycle tied to the vendor in a much stronger way. SmartCards are going to be painful (need readers) until contactless cardreading hits laptops and desktops in a big way. -The driver for this is going to come from the move to embed RFID stuff I think.

Anonymous said...

I use pms(http://passwordms.sourceforge.net/).

Anonymous said...

I would be interested in seeing what it looks like. Right now I have been basically doing what you are, without a script. Encrypting/Unencrypting a text file, with my passwords in it, by hand... it can get very tedious.

- John

Julio M. Merino Vidal said...

John: I hope to post it somewhere soon (possibly Sourceforge). What started as a stupid and hackish utility is now autotoolized and has a manual page. At the moment, I'm working on a regression test suite to ensure that everything works as expected :-)

Jason Thorpe said...

Have you looked at Keychain in Mac OS X? Your idea is very similar, but Keychain is fairly comprehensive. For example, in OS X, it also serves as the repository for X.509 root certs, etc.

I would love for NetBSD to have Keychain-like functionality.

Julio M. Merino Vidal said...

So far I hadn't used Keychain "directly"; I mean, I let the applications store their information in it, but that's all.

I've been playing now with the program, creating a keychain in a USB drive, testing the "secret notes", manual addition of passwords, etc. Certainly looks nice. (I'm still unsure on what kind of automation you can achieve if you keep your main keychain in a removable drive.)

It'd be great if there was a free program that understood that format so that it'd be directly used in other systems (e.g., KDE's Wallet or GNOME's keyring).

About having similar functionality in NetBSD... I don't know how that could be achieved... if it has to be at the desktop level, you either have a KDE or a GNOME application and then it loses relation to NetBSD. Or you meant something else?