This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


How to create a command-line password vault

By Duane Odom on March 16, 2007 (7:00:00 AM)

Share    Print    Comments   

Like many people, I have too many passwords to remember. To keep them straight, I wrote <slash type="file" id="10317d05b9867bdb30aeb5cb5576ac73" title="passwd_locker">a simple password security script</slash> using dialog and GnuPG (GNU Privacy Guard). The script prompts the user for a master password using a dialog box, unencrypts a file that holds a list of passwords, and opens the file in a text editor. When the editor is closed, the script re-encrypts the password file.

Dialog is an ncurses-based utility for providing text-based message and input boxes. GnuPG is a free implementation of the OpenPGP standard. Both applications are available as binary packages on Debian-based systems.

First, I had to create an encryption key using the command gpg --gen-key. I was prompted for the type of key I wanted to generate. Some keys were labeled "sign only," but I needed to use my key to encrypt data, so I selected "DSA and Elgamal" (which wasn't marked sign only). The only other important thing about the questions that followed was that I needed to remember what I typed when prompted for the "Real Name," because it is used when you encrypt.

Once I successfully generated my key, I needed to create a password file and encrypt it. I created a text file called passwords, typed in some URLs and passwords, and saved the file. Next, I ran the command gpg -e -r "Duane Odom" passwords, which encrypted the text file to another file named passwords.gpg using the recipient "Duane Odom" (the "Real Name" that I typed in while generating my key). Finally, I needed to delete the unencrypted version of the passwords file.

Now that I had my GnuPG key generated and an encrypted version of my passwords file, I could create my password script. The first line creates a suitable temporary file name using the command tempfile. The next line ensures that no matter how the script exits, the temporary file gets deleted. The last line uses dialog to prompt the user for the GnuPG password and redirects dialog's standard error, which provides the actual text that the user typed, to the tempfile that the script created. The dialog command uses the return value to inform you whether the user selected the "Ok" button, the "Cancel" button or the program had an error. The return value is 0 if the "Ok" button was pressed, 1 if the "Cancel" button was pressed, and -1 if an error occurred or the "Esc" key was pressed (as the dialog man page specifies, most shell scripts can't distinguish between -1 and 255, so the script uses the more standard 255).

TEMPFILE=`tempfile 2>/dev/null` || TEMPFILE=/tmp/`basename $0`.tmp
trap "rm -f $TEMPFILE" 0 1 2 5 15
dialog --backtitle "Password Database" --title "Master Password" --clear --insecure --passwordbox "Enter the Password Database master password." 10 51 2> $TEMPFILE

The next important line in the script is where the password file is decrypted. I use the cat command to send password from the file to gpg, and use the --passphrase-fd 0 parameter to tell gpg that the password is being given via standard in:

cat $TEMPFILE | gpg -d -r "$KEY_RECIPIENT_NAME" -o $PASSWD_LIST_UNENCRYPTED --passphrase-fd 0 $PASSWD_LIST &> /dev/null

The next line opens the unencrypted password file in the user's default editor. The script then waits for the editor to terminate (you close the editor when you are finished) and the next line encrypts the password again. The final line removes the unencrypted version of the file:


The handy thing about this script is that (with slight modifications) you can use it to store other documents, images, slide shows, etc., in an encrypted format and still have easy access to editing them. If you have a set of files that you'd like to keep encrypted, you might consider using TrueCrypt instead to create a virtual encrypted disk within a file and mount it as a real disk.

You should never blindly trust anyone's scripts, especially when it comes to your security. As always, read the man page for gpg and dialog for more information on those applications.

Duane Odom is a computer programmer for the US Department of Defense and a freelance writer. He has been a Linux user since 2001.

Share    Print    Comments   


on How to create a command-line password vault

Note: Comments are owned by the poster. We are not responsible for their content.


Posted by: Anonymous Coward on March 16, 2007 11:28 PM
There is already a program out there, called Gringotts, that does precisely this and much more. It is, I think, already part of most distributions. Even though I think this is a useful article -- I have certainly learned from it -- I sometimes wonder where FOSS could be if people spent less time duplicating the same functionalities...


On the other hand...

Posted by: Anonymous Coward on March 16, 2007 11:57 PM
I doubt that *I* would have heard of Gringotts, if there hadn't been someone who took the time to duplicate some of its functionality. A few hours of his time, coupled with your comment, opens eyes to the possibilities that are out there.

Besides, managing your programming assets isn't a feature of the open-source model; it's part of that *other* model... you know, the one the evil empire uses... and they have gotten so bogged down trying to maintain their dominant position that they can't get around to *coding* anymore.

All things considered, FOSS is fine the way it is.

Geek Unorthodox



Posted by: Anonymous Coward on March 17, 2007 12:17 AM
I think FOSS is all about duplicating efforts, really. I we all agreed on anything and everything, there wouldn't be competition and there --possibly-- wouldn't be progress.



Posted by: Anonymous Coward on March 17, 2007 12:21 AM
A lot of what we do in Open Source can be considered self-enrichment. That means we do things that make ourselves better -- better programmers, better administrators, better power users, and more. This man's "duplication of efforts" undoubtedly forced him to think critically, and perform research. Even if no one else ever uses his script, HE is better for creating it.

Your implication of his efforts as being 'of little use' is incorrect. He might become (or might already be) the next contributor to the kernel, or KDE, or another important project. We all need practice. All of us.

- just some guy



Posted by: Anonymous Coward on March 17, 2007 01:40 AM
Yeah, sure, I agree with all that -- still, how many times do you come across yet another utility or editor or whatever which looks promising and then you find out that it is half-finished because it was basically written as an exercise in "self-enrichment" and then abandoned? (Sourceforge is full with such programs.) At times like that, you wish others would take the existing project up rather than reinventing the wheel.


Re: Gringotts

Posted by: Bruce Ferrell on September 29, 2007 08:35 PM
except Gringotts seems to now be defunct. I have to run it under vmware/suse 9.3


Simple solution

Posted by: Anonymous Coward on March 17, 2007 12:01 AM
A simple solution from the book "Linux Security Cookbook" (O'Reilly, June 2003, ISBN : 0-596-00391-9) is to create a text file with all accounts in a same format (e.g. logintabpasswordtabcomment) and encrypt this with GnuPG. With this little bash script, you can search for entries in the file.
<tt>  #!/bin/bash
 <nobr> <wbr></nobr>/usr/bin/gpg -d $PWFILE |<nobr> <wbr></nobr>/bin/grep -i $@</tt>
In the bash you can type mypass ebay and you will get rows include ebay.


Re:Simple solution

Posted by: Anonymous Coward on March 17, 2007 12:54 AM
That's exactly what I do; the passwords are in a colon-delimeted plain text file. I skipped one step, though: GnuPG. (shh, don't tell anybody...)


pwsafe anyone?

Posted by: Anonymous Coward on March 17, 2007 12:19 AM
I realise sometimes it's fun to write code just to explore a problem. Especially in the areas of security and encryption, however, I think it's especially valuable to look for standard utilities out there and see if they meet your needs. The chances are they've been scrutinized for vulns to a degree you're own script never will be.

With that in mind - how about pwsafe? Command line user/pw locker with master password that can save output to the X clipboard (for convenient pasting) and supports synchronising of multiple db files... It fits the way I work at least...


Re:information leakage

Posted by: Anonymous Coward on March 17, 2007 02:08 AM
Wouldn't TrueCrypt work for this sort of thing? You could create a virtual drive for your pw file...


Cleartext on disk

Posted by: Anonymous Coward on March 17, 2007 05:03 AM
It should be decrypted into RAM.
It gets gets temporarily decrypted to the disk, that seems insecure, since stuff you delete from the disk, are not really gone, it can be recovered.


Screen command

Posted by: Anonymous Coward on March 17, 2007 06:49 AM
The screen command, along with all its other useful functionality provides this. Ctrl-a Ctrl-x locks the screen until you enter the login password for the session.


Re:Screen command

Posted by: Anonymous Coward on March 17, 2007 06:53 AM
While the documentation says Ctrl-a Ctrl-x to lock the screen, on Fedora, this appears to actually be Ctrl-a X (control-a shift-x).



Posted by: Anonymous Coward on March 17, 2007 11:39 PM
Hi there

I applaud your efforts in making these kind of scripts, but I suggest you instead have your passwords on your Linux desktop.

Then you can use the Kgpg program that will decrypt a file and display the result on screen, without making any temporary files.

PS: encryption is like a lock, and the only thing locks give you, is time.

That said, what about the original source file, you obviously delete it, but files can be un-deleted, and partitions can be un-formatted

Better to never ever save the unencrypted file to disk at all.


redundant security

Posted by: Anonymous Coward on March 18, 2007 06:50 AM
There mite be a linux opportunity for those upgrading there system for propriety software. This mite allready be availably however what about a knoppix live cd with the best available security suite configured to run as an only (motherboard,-amd,intel for starters-,ram, two dvds-one read only the other burnable-) configuration. People chosing a new system are introduced to linux as they use the old system as an internet fire wall. The interface would have no loging features or personal data it would be a gate keeper or sentry for people using propriety software. If OS logs were kept any time there was a problem one of the dvds normaly empty could be used for a live disk that called a website and reports the current state. If it was caused by a software problem the state would be available for debuging. If a filter update was needed, the call in would report the malicious culprate. This allows users to participate in a group search for malware and use the result to creat some type of super fortress. Also any time the system crashed an off/on reboot would clear mem. fixing the hang up untill it happened again. Along a simmilar line there appears to be room in a 5U case for two face to face mobos with pci* cards or up to 4 mother boards configured ([][]) with water cooling and no pci cards. I'd like to see drivers that help multi board (cluster) systerm configure using a pci, pci-e, hypertransport, jumper cables among usb, nic, etc. interfacing to help promote the idea of clustering old systems for internet interfacing or background processes. And promote the idea of computing for humanatarian benefits even if you don't use all your cpu cycles, let the weather service or people willing to use a community net that can't schedule a supper computer. Each computer owner could select projects interested in a group application like protein folding. This would promote computing for computing sake and its potential to serve humanity even if a person has little interest beyon sending a letter or watching TV.


Re:redundant security

Posted by: Anonymous Coward on March 18, 2007 04:25 PM
LOL, very good, nice brain dump.

But seriously, WTF?


Re:redundant security

Posted by: Anonymous Coward on March 23, 2007 03:48 PM
That was a spam/robot post, in case it wasn't obvious. Instead of using random words it uses established sentences (or groups of sentences) and strings them to together.


Even better still..

Posted by: Anonymous Coward on March 19, 2007 02:33 AM
Commit all passwords to YOUR memory and do away with the GPG-encrypted file/script/etc altogether.


I use Vim as a password safe

Posted by: Anonymous Coward on March 21, 2007 01:57 PM
See Vim script 1833 for des3.vim:

        <a href="" title=""><nobr>8<wbr></nobr> 33</a>

As long as you have openssl on your system
this allows editing of des3 encrypted files.
This also add some specific password safe features
to make browsing of password files easier.

Vim has built-in encryption if you somehow don't
have openssl installed; however, the built-in
encryption is not as strong as des3.


Using shred

Posted by: Anonymous Coward on May 08, 2007 04:40 AM
If you don't want to go the vim-plugin route, you can also add "shred $PASSWD_LIST_UNENCRYPTED;" right above the "rm $PASSWD_LIST_UNENCRYPTED;" to destroy the file's contents before deleting it.


information leakage

Posted by: Administrator on March 17, 2007 12:39 AM

The decrypted file is left in the clear on disk. For editing, this may be a necessary evil, but for only viewing the file (because you needed to retrieve a password), there is no need to have the contents on the disk, linked to a filename, for viewing.

I suggest these changes to tighten the security during data viewing:

  1. Read the entered password into an environment variable, rather than creating a disk file. (Not all<nobr> <wbr></nobr>/tmp mounts use tmpfs.) Use "echo var" rather than "cat file" to feed the password to gpg.

  2. Pipe the gpg decryption to a pager ("more" or "less"). No on-disk file is needed for viewing only.

  3. Put the viewer into the background, and immediately scrub the password variable. This shortens the time the password is viewable in<nobr> <wbr></nobr>/proc/(pid)/environ. Once sensitive information is wiped, you can "wait" for the viewer to exit.



Posted by: Administrator on March 18, 2007 03:07 PM
There is a nice vim plugin called "gnupg", that will do the same thing, except decode only into memory:<nobr>6<wbr></nobr> 1


Use VIM to avoid problems with temp files, etc.

Posted by: Administrator on March 17, 2007 03:47 AM
<a href="" title=""><nobr>5<wbr></nobr> 1</a>

has a section on creating a password safe using GnuPG.


How to create a command-line password vault

Posted by: Anonymous [ip:] on December 18, 2007 12:23 AM
Otherwise, if don't mind a graphical program, Revelation Password Manager does all this, and even includes features like password generation, tray applet access, etc. You can find it at


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya