GPG-Based Password Wallet
Like many Internet addicts, I have way too many user name/password accounts to remember: accounts on social-networking sites, rarely used logins at work, on-line banking and so on. One solution to this problem is to use the same user name and password everywhere, but that's clearly not safe; if people get a hold of your account information in one place, they own all your other accounts too.
I wanted a relatively safe, flexible and easy way to store passwords and other useful confidential information. I also wanted it to be easily accessible, which meant that I'd like to get at it over a text-only SSH connection. And, I wanted it to be something that could move around from machine to machine without too much trouble.
A few months ago, I saw an article by Duane Odom on linux.ocm about a shell script that uses GPG to encrypt and decrypt a text file containing the user's list of passwords (or any kind of text). I liked this approach, as it met the following requirements:
It stores passwords in a well-encrypted text file (protected by a master password). The text file could contain anything and be formatted any way I want.
The entire interface is text (an ncurses password interface, followed by less or a text editor like vim), so you can access it over a nongraphical SSH session (see the Accessing Your Password Wallet from the Computer at Your Friend's House sidebar).
The script is built on standard utilities common to most Linux distributions (gpg and dialog).
Accessing Your Password Wallet from the Computer at Your Friend's House
One of things that has made wallet useful to me is the ability to reach it from anywhere. Here are a few hints for enabling SSH access to your broadband-connected Linux box at home.
Rather than try to memorize your computer's IP address (which may change unexpectedly anyway), you could sign up for a free dynamic DNS service like DynDNS. This lets you choose a memorable hostname for your computer, something like carlslinuxbox.dyndns.org. Some of these services want you to update your DNS record periodically (I think dyndns.org wants that to happen at least once a month). Rather than do that by hand, you can run an auto-updater (like inadyn) in cron. Be careful when setting the update frequency—some dynamic DNS services suspend your account if you update too often (read the fine print).
If you're going to let the Internet talk to SSH on your Linux box, there are a few things you can do to make that a bit more secure. I recommend disabling the PermitRootLogin option in the sshd_config file. You also may want to run SSH on a nonstandard port using the Port option in sshd_config. If the script kiddies find SSH running on port 22, they'll throw a bunch of user names and passwords at it trying to break in. Running SSH on a port other than 22 discourages this sort of thing to a large degree. And, make sure your firewall allows access to whatever port you use. Finally, if your computer is behind a consumer cable/DSL router, you'll have to configure the router to forward SSH traffic to your Linux box.
With those things done, next time you're at a friend's house, you could jump on a computer, download an SSH client (such as putty) and SSH to your Linux box (remembering to tell the SSH client your dynamic DNS hostname and the port number on which you're running SSH).
Although I liked the way the original script worked, I wanted to add several features. So I made some alterations to the original, and the result is shown in Listing 1.
Listing 1. wallet Script
1 #!/bin/bash
2
3 . ~/bin/functions
4 is_installed gpg
5 is_installed dialog
6 is_installed mktemp
7 is_installed basename
8
9 if [ -f ~/.walletrc ]; then
10 . ~/.walletrc
11 fi
12
13 if [ -z $VISUAL ]; then
14 VISUAL=vi
15 fi
16
17 EDIT_PWFILE=0
18 while getopts 'ec:' OPTION
19 do
20 case $OPTION in
21 e) EDIT_PWFILE=1;;
22 c) WALLET_FILENAME="$OPTARG";;
23 ?) printf "usage: %s [ -e ] [ -c encrypted_file ]\n" \
24 $( basename $0 ) >&2
25 exit 1
26 ;;
27 esac
28 done
29 shift $(($OPTIND - 1))
30
31 if [ -z "$WALLET_FILENAME" ]; then
32 echo "need the encrypted file specified by WALLET_FILENAME"
33 echo "(in ~/.walletrc or the envariable) or with the -c option"
34 exit 2
35 fi
36
37 if [ ! -f $WALLET_FILENAME ]; then
38 echo "$WALLET_FILENAME doesn't exist--attempting to create..."
39 echo "(you'll need to give gpg a master password)"
40 mkdir -p $( dirname $WALLET_FILENAME )
41 TEMPFILE=$( mktemp /tmp/wallet.XXXXXX )
42 gpg -c -o $WALLET_FILENAME $TEMPFILE
43 rm -f $TEMPFILE
44 EDIT_PWFILE=1
45 fi
46
47 if [ $EDIT_PWFILE -eq 1 ]; then
48 is_installed $VISUAL
49 fi
50
51 # prompt the user for the password
52 PASSWORD=$( dialog --stdout --backtitle "Password Wallet" \
53 --title "Master Password" --clear --passwordbox \
54 "Please provide the master password." 8 40 )
55 if [ $? -ne 0 ]; then
56 echo "Failed to acquire master password"
57 exit 4
58 fi
59 if [ -z $PASSWORD ]; then
60 echo "Password is required"
61 exit 8
62 fi
63
64 # if we're not editing the file, just display it and quit
65 if [ $EDIT_PWFILE -eq 0 ]; then
66 echo $PASSWORD | gpg --decrypt --passphrase-fd 0 \
67 $WALLET_FILENAME | less
68 clear
69 exit 0
70 fi
71
72 # set up the directory in which the unencrypted wallet file
73 # will be edited
74 TMPDIR=$( mktemp -d /tmp/wallet.XXXXXX )
75 CLEARTEXT_WALLET_FILENAME=$TMPDIR/wallet
76
77 # try to ensure that cleartext wallet file is deleted,
78 # even after unexpected terminations
79 trap "{ rm -rf $TMPDIR; }" 0 1 2 5 15
80
81 # decrypt the password wallet--an error here probably means
82 # the user typed the wrong password to decrypt the wallet
83 echo $PASSWORD | gpg -o $CLEARTEXT_WALLET_FILENAME \
84 --passphrase-fd 0 \
85 $WALLET_FILENAME &> /dev/null
86 case $? in
87 0)
88 # decryption succeeded, so open the wallet in the editor
89 # and then re-encrypt it when the editor closes
90 mv $WALLET_FILENAME ${WALLET_FILENAME}.bak
91 $VISUAL $CLEARTEXT_WALLET_FILENAME 2> /dev/null
92 echo $PASSWORD | gpg -c -o $WALLET_FILENAME \
93 --passphrase-fd 0 \
94 $CLEARTEXT_WALLET_FILENAME &> /dev/null
95 if [ $? -eq 0 ]; then
96 clear
97 else
98 LAST_RESORT_FILENAME=$( mktemp ~/wallet.XXXXXX )
99 cp $CLEARTEXT_WALLET_FILENAME $LAST_RESORT_FILENAME
100 chmod 600 $LAST_RESORT_FILENAME
101 echo "gpg failed to enrypt your password wallet: I have"
102 echo "tried to put a CLEARTEXT copy of your wallet at"
103 echo $LAST_RESORT_FILENAME
104 exit 16
105 fi
106 exit 0;;
107 ?)
108 echo "error condition detected (invalid password?)"
109 exit 32;;
110 esac
It's pretty easy to install; simply save the script somewhere in your $PATH and make it executable. Then, you just need to tell it where your encrypted password file should be. There are three ways to do this:
Set the $WALLET_FILENAME environment variable.
Set $WALLET_FILENAME in ~/.walletrc.
Specify the filename with the -c command-line option.
The second method (which overrides the first method) is my preference—I have the following line in ~/.walletrc:
WALLET_FILENAME=~/docs/wallet.gpg
But, if I needed to use a different wallet file, I could override either of the first two methods with the command-line option by calling the script like this:
wallet -c ~/docs/other_wallet.gpg
wallet defaults to its read-only mode, in which it displays the decrypted version of your wallet file using less. But, if you include the -e command-line option (edit mode), the script decrypts your wallet file to a temporary location and opens it in a text editor (the script defaults to using vi, but you can set the $VISUAL variable in the environment or in your ~/.walletrc file). When you close the editor, wallet encrypts the file and saves it to the original location.
The first time you run wallet, you won't have a wallet file, so wallet creates it for you and runs in edit mode.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
3 hours 41 min ago - Dynamic DNS
4 hours 15 min ago - Reply to comment | Linux Journal
5 hours 14 min ago - Reply to comment | Linux Journal
6 hours 4 min ago - Not free anymore
10 hours 6 min ago - Great
13 hours 53 min ago - Reply to comment | Linux Journal
14 hours 1 min ago - Understanding the Linux Kernel
16 hours 16 min ago - General
18 hours 45 min ago - Kernel Problem
1 day 4 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
Just use vi directly
Besides the issue with echo $PASSWORD already mentioned, this also puts a cleartext version of your secrets on disk, in tmp files, etc. Although there is an attempt to clean it all up, it's still rather messy and overly complex.
If you use vi, you can edit the gpg files directly with no cleartext ever touching the disk. And it's much simpler.
http://www.antagonism.org/privacy/gpg-vi.shtml
... and even worse: echo
... and even worse:
echo $PASSWORD | gpg --decrypt --passphrase-fd 0
$PASSWORD will be visible to every local user, in cleartext on process list (ps command)
well...
well, it's nice idea to use shred instead of rm. with rm -f you are deleting link to the inode, but inode itself is left untouched. on BSD rm -P should be sufficient.