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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
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
| 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 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Trying to Tame the Tablet
- git-annex assistant
2 hours 55 min ago - direct cable connection
3 hours 17 min ago - Agreed on AirDroid. With my
3 hours 27 min ago - I just learned this
3 hours 32 min ago - enterprise
4 hours 2 min ago - not living upto the mobile revolution
6 hours 53 min ago - Deceptive Advertising and
7 hours 28 min ago - Let\'s declare that you have
7 hours 29 min ago - Alterations in Contest Due
7 hours 30 min ago - At a numbers mindset, your
7 hours 32 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.




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.