Encrypted and Remotely Synced Password List with Zim Desktop Wiki and Friends

Passwords are problematic. This guide shows you how to manage a personal password list with multiple copies on different computers, synchronization among the computers, and encrypted storage. You'll need to be at least somewhat familiar with your system's command prompt and with unix in general to follow the guide, but you should be able to implement this scheme on any desktop Linux, OS X, or Windows computer.

[TOC]

1. Introduction

Note: This guide uses Zim Desktop Wiki and encfs as two separate components. Shortly after I published it, a new version of Zim was released with new internal functionality to mount and unmount fuse filesystems such as encfs. I will probably update this guide in the future to relfect this, but in the mean time, if you are using version 0.27 or later of Zim, you may either follow my instructions exactly and ignore the fuse functions inside Zim, or use Zim's fuse mount/unmount functions however they best work for you. 14 November 2008

I'm lazy, and I don't want to memorize a bunch of different passwords for every online account I have. So, suppose I had one password that I used everywhere. This is incredibly insecure; if any one of my many accounts is compromised in a way that reveals the password, an attacker could then use that password to login anywhere else I have an account!

This is why most people have a handful of passwords, for example, one for Gmail, one for "random online services" and one for "bank stuff". This isn't really much better than the one-password scenario. Suppose I use the same "random online services" password on Facebook that I use on some poorly-programmed low-traffic forum a friend told me to join. Suppose an attacker breaks into that forum and recovers my password. Now they have the key to my Facebook account! (In reality, I wouldn't cry if my Facebook account was compromised, but you get the idea.)

Clearly the safe thing to do is to use a new, unique password for every new system account you setup. And since you probably can't or don't want to memorize that many unique passwords, you're going to need a password manager program.

I've tried a few different password management programs over the last few years and none of them have really fit my needs. I used Revelation for a long time, and I checked out KeePass and Ked Password Manager, but I couldn't find any desktop apps that were both multiplatform and capable of syncing separate copies of your data.

I like working in mobile, portable computing environments. I want to be able to see the some of the same files at home as I do on my work desktop. I want to be able to run applications remotely from home and have them display on my work desktop. And where speed is important (as is the case with looking up passwords in your password list), I keep distinct copies of the apps and data and synchronize them periodically.

I recently discovered Clipperz, which is an excellent web-based password manager. All of your data is stored on the web server in encrypted form, and all the encrypting and decrypting of data happens entirely inside your web browser. Anyone that has less than 50 or so passwords should check it out. But it has two major drawbacks: You can't store parent/child relationships; all your passwords are in a single flat list. And it's frustratingly slow on anything but the fastest computer, since it's performing cryptography in Javascript code, which isn't well-suited for number-crunching.

I can't find one program to do everything I want, but it occurred to me that I could build the functionality I want out of smaller open-source components that already exist. Here are my requirements:

• A desktop-based account/login list editor with the ability to store and retrieve hundreds of passwords. (I'm a programmer and I touch a lot of systems.)
• Must be able to synchronize separate copies of the data living on different computers.
• Data should be stored in plain text files or something else that's easy to manipulate and move data in and out of. Syncing is a lot easier with plain text files than with anything else
• Data must stored on disk in encrypted form
• The whole scheme has to work in Linux (my primary OS), Windows, and OS X.

One of the core rules of Unix philosophy is "Do one thing, and do it well." I don't really need one program to satisfy all of the requirements above; I just need a collection of programs that together satisfy the requirements. Here is what I've chosen, all of which are programs I'm already quite familiar with:

Editor: Zim Desktop Wiki is a single-user rich text editor/outliner for your desktop. It stores all its data in plain text files. Folders in the wiki are folders in your filesystem, and pages are text files in those folders. Zim provides instant searching of wikis via a background indexer that updates itself every time you change a page. Zim works on every major desktop OS.

Note that another advantage of using Zim is that I don't really need access to Zim to casually browse and edit my passwords. With nothing but ssh and a text-mode terminal, I can log in remotely and retrieve a password.

Synchronization: Unison synchronizes multiple disconnected copies of data sets stored in files. It gracefully handles ad hoc synchronization of any two peers in the group of two or more, with no central server. It correctly handles new files, deleted files, and renaming. It only propogates the differences from one copy of a file to another, so minor edits to huge files are synchronized quickly. Unison also works on every major desktop OS.

Encryption: EncFS is my favorite unix-based file encryption tool. It allows you to setup ad hoc encrypted folders on top of any filesystem (local or remote). It doesn't require you to preallocate a certain amount of space; instead, each file is stored individually on the underlying filesystem as a separate file, with its name and contents encrypted. (This means that the number of files, their sizes, and date stamps are unprotected, but I can live with that.) Best of all, EncFS folders are only accessible to their owner when they're online. Even a process running as root can't access them directly without first changing its login context to the folder's owner. The best Windows alternative to EncFS is TrueCrypt (which is also available for Linux and OS X). TrueCrypt does require you to preallocate space for your encrypted data.

Glue: It's nice to have a few pieces of scripting glue code to tie this together so that, for example, I want a single command that will 1) check to see if the encrypted folder is mounted, 2) mount it if necessary, and 3) start Zim. I used the fish shell, which most people have never heard of. I use fish because I'm obstinate and I still haven't taken the time to learn bash. YMMV.

Here's how you put it all together:

2. Setup Zim Desktop Wiki

Install Zim Desktop Wiki from the web site or from your favorite package manager. Launch Zim and it will create a new empty wiki for you. You can use this later for storing unencrypted notes, but for passwords, let's setup a new wiki in a particular location:

1. Use the File → Open Another Nokebook command, then click Add to add a new wiki.

   

2. Use the Browse button to create and select a new folder ~/notes/enc-logins to contain your new wiki. (Use whatever name you like, but in this guide I'll be calling it enc-logins with the enc prefix being my convention for encrypted folders.)

3. Set the name to Logins and click OK.

Now add some new empty pages to your password wiki for your top-level categories. Here are some examples:

If you have trouble figuring out how to create and navigate pages in Zim, hit F1 and read the Help file.

Now start entering all your passwords. Here is a concise format that I've arrived at with a little bit of experimentation:

Each username/password pair is given on one line with a "/" between them. Notes and extra security questions are given in italics, and account titles are given in bold. Notice that each password is a long random string and that a "password recovery" question's answer is just another password. See more of my personal password rules in the last section of this guide.

3. Encrypt Your Password Wiki

When you're done loading all your passwords into your wiki, it's time to encrypt it. If you haven't already installed it, install the unix package "encfs" on your system. (Run apt-get install encfs if you're on a Debian-like or Ubuntu system.)

Now encrypt the folder:

cd ~/notes
mv enc-logins temp  #put unencrtypted contents aside
encfs ~/notes/.enc-logins ~/notes/enc-logins  #create an encrypted folder enc-logins backed by .enc-logins
# Follow prompts and set a passphrase (the master password to protect your stored passwords).
# enc-logins is now an encrypted folder, and it is mounted.
mv temp/* enc-logins  #move wiki contents into encrypted folder
rm -r temp #remove leftover Zim index and temp folder itself

Some clarification for those who are new to EncFS:

~/notes/.enc-logins is a real folder on your home filesystem. The files in your encrypted folder are stored here with encrypted data and encrypted filenames. Because the name begins with a ".", you won't see it in a directory list unless you need to view notes with Show hidden files turned on.

~/notes/enc-logins is a virtual folder, the contents of which are created by EncFS when you mount .enc-logins. This is where you access the files and see them as if they were not encrypted. When you unmount the folder, the contents of enc-logins disappears, leaving an empty folder.

And a quick gotcha if you're unfamiliar with how unix mounts filesystems: if you put files in enc-logins when it's not mounted, the mount command will fail. To resolve this situation, just move the accidentally-created files elsewhere and try again to mount it.

I won't go into the details of setting up an encrypted folder with TrueCrypt instead of EncFS. From what I've heard, it's relatively painless, so if you're on a Windows system and you can't use EncFS, go ahead and read the manual for TrueCrypt and come back here when you've got it working.

4. Create a Launch Script

Prerequisite: make sure you have the package xdialog installed.

This section is unix-specific. If anyone has a good solution for traslating these two scripts to a Windows environment with Zim + TrueCrypt, let me know and I'll post it here.

Either install fish and create this script, or translate it to bash.

mkdir ~/bin
cd ~/bin
touch enc-logins  #create script file
chmod +x enc-logins  #make it executable
nano enc-logins  #(or use your favorite editor)

~/bin/enc-logins

#!/usr/bin/fish

# Mount ~/notes/enc-logins if necessary, then launch Zim.

set data ~/notes/enc-logins
set data_encrypted ~/notes/.enc-logins
set mount_name enc-logins

grep $mount_name /proc/mounts >/dev/null
set unmounted $status

if test $unmounted != 0
    Xdialog --title "Logins wiki" --password --inputbox "Password for $data:" 0x0 2>|read password
    echo $password|encfs -S $data_encrypted $data
end

grep $mount_name /proc/mounts >/dev/null
set unmounted $status

if test $unmounted != 0
    Xdialog --title "Logins wiki" --msgbox "Failed to mount $data." 0x0
else
    zim --no-daemon $data Home
end

If you wish, create a launcher in your desktop's menu system to run that script.

You can also create a script to unmount the encrypted folder:

~/bin/lock-enc-logins

#!/usr/bin/fish

# Unmount ~/notes/enc-logins and report success or failure.

set data ~/notes/enc-logins
set mount_name enc-logins

fusermount -u $data

grep $mount_name /proc/mounts >/dev/null
set unmounted $status

if test $unmounted != 0
    Xdialog --title "Logins wiki" --msgbox "Successfully unmounted $data." 0x0
else
    Xdialog --title "Logins wiki" --msgbox "Unmounting $data failed. Perhaps you still have files open." 0x0
end

5. Setup Synchronization

Prerequisite: unison requires ssh (client) on the computer that is initiating a sync connection and sshd (server) on the computer accepting the connection. Google for help if you don't know how to setup ssh.

Install Unison on each computer that will be performing synchronization.

Create a Unison profile on the computer that will be initiating the connection:

~/.unison/enc-logins.prf

root = ~/notes/enc-logins
root = ssh://USERNAME@HOSTNAME//home/USERNAME/notes/enc-logins

(Be sure to fill in USERNAME and HOSTNAME.)

Alternatively, if you want to dispense with ssh and use some other file sharing mechanism such as Windows File Sharing (SMB protocol), go ahead and set that up, and give unison the local and remote paths as they appear on the client machine. For example, $MYDOCUMENTS\enc-logins and R:\enc-logins. The actual Unison program will only be running on the client side in this case, so it will be forced to read the entire remote folder across the network to deterine what has changed. When you use ssh, unison is actively executing on both ends and the two processes compare notes over the network; this method is faster.

Before you run Unison, make sure the encrypted folders are mounted on both sides of the connection. (Alternatively, you can synchronize the hidden, raw .enc-logins folders, but if you do that, you won't have the opportunity to resolve conflicts in the case where the same file was edited on both sides.) When you're ready, run the command: unison-gtk enc-logins .

If you've edited files on both sides before syncing, Unison will register a conflict on the binary files in the .zim folder. You can pick either side to win (Right to Left or Left to Right) or simply tell unison to ignore the entire .zim folder; Zim automatically derives the contents of the .zim folder from your real data files (*.txt) anyway.

If Unison detects a conflict in any text files, that means you edited the same page on both sides of the connection. Use the Merge command to merge the new data from both copies into a new unified page.

Also, if you don't want to type your SSH password every time you run unison, learn how to use a public key to log into an SSH server.

6. Generating Passwords

If you commit to using unique passwords every time you create new accounts, it quickly becomes obvious that creating new passwords is itself a small problem. (Mashing your hands on the keyboard is not the answer; it's not random enough.) Fortunately there is a solution to that, too. Install the package "apg" and add these hints to your password wiki:

# long password:
apg -a1 -m19 -x19 -Msncl

# long alphanumeric only password:
apg -a1 -m19 -x19 -Mcnl

# short password:
apg -a1 -m8 -x8 -Msncl

# short alphanumeric only password:
apg -a1 -m8 -x8 -Mcnl

# pronounceable password:
apg -a0

Running the first of these commands on the command prompt generates a set of random 19 character passwords using letters, numbers, and symbols. The next three are variations on that theme. The last command generates an 8 to 10 character password made up of pronounceable syllables, which is easier to commit to memory.

Each time you assign a new password on a system, run apg with the most secure options you want to. Use shorter and alphanumeric-only variations when a stupid system requires that you don't use symbols or that your password be shorter than some length. (I've seen both restrictions.) Store the password in your wiki and also set your browser or other network client remember it.

You will probably have a small number of logins on systems that require you to type the password by hand every time. In this case, use the "pronounceable password" options so it's easier to memorize.

7. Backup Procedure

Make sure your passwords folder is mounted, and simply use your favorite archiving program (Zip, 7-Zip, RAR, etc.) to create an archive of the folder, encrypted with a password. In a disaster recovery situation, all you need to read this backup is the archive program and a text editor.

Store your backup at a different physical location. House fires and other such disasters are traumatic enough, and you don't want to get locked out of your entire online life and feel even worse!

8. Best Practices

1. Always create a new unique password every time you create a new account on any system.
2. Use a random password generator to get the most random password you can. Anything you come up with in your head will be less random and less secure than the output of a random number generator.
3. Change passwords on sensitive accounts regularly.
4. Don't share your passwords with your friends. If you're forced to share one, change it later.
5. Don't share your passwords with other web sites! Yes, Facebook might have a legitimate need to see my Gmail address book so it can instantly determine who I know that's already on Facebook, but allowing Facebook to login to my Gmail account with complete access is absolutely not an acceptable way to grant this request.
6. Don't share your passwords.
7. Lock your passwords folder by unmounting it, when you're not using it.
8. Back up your passwords folder regularly to a different physical location.
9. Save your passwords in your web browsers and other desktop apps, but be aware of the security ramifications. Safari and Konqueror store web site passwords in a database encrypted with a key you choose. Firefox and Opera do not let you choose the key, and they are quite vulnerable to a physical attack on your computer.
10. Don't use passwords. :^) In some instances where they might be available, you might find other schemes like public key authentication to be more convenient or more secure.

Bonus: If a system forces you to answer a "password recovery" question like "favorite pet" in my example above, don't answer truthfully. Instead just pick one of the questions and answer it with a new password --- and record the question and answer in your password list. Birthday, Zip Code, and "Where did you meet your spouse?" are not exactly private data points that no one could ever guess!

Comments