How to best store sensitive information without a password manager?

thayer · 2008-02-06 20:12:04

I've been using the Revelation password manager for some time now to store sensitive material for family and work. It meets most of my needs, but it has some hefty GNOME dependencies and I'd really like to use something with a bit more flexibility. Is there a solution that can provide the following:

* serious encryption
* opened via password
* store lots of account info for personal use and clients
* ability to store notes of various lengths
* accessible from the console when necessary

I've tried a number of password managers and they're all lacking in some way--either the encryption isn't strong enough or they're X11-based. I'd be happy with a bash function that ran a series of commands to encrypt/decrypt a text file or something similar.

Any suggestions?

Last edited by thayer (2008-02-06 20:15:05)

cactus · 2008-02-06 20:21:18

maybe a truecrypt (or encrypted loopback) encrypted file?
you can mount and unmount it as needed, store notes, passwords, whatever inside it, and back it up as a whole file without compromising the security.
When mounted, it is also accessible from the command line.

truecrypt is kind of neat, since it can be used cross platform, and you can enabled the plausible deniability mode, where there is a hidden container inside the container.

Dusty · 2008-02-06 21:09:04

I just use gnupg to encrypt a text file. Well I used to. Now I just keep it in my head so you'll have to torture me.

Dusty

thayer · 2008-02-06 23:07:46

Thanks guys, I'll spend some time looking at both solutions. Truecrypt sounds intriguing though and might help alleviate my paranoia of nunchuk-wielding squirrels.

drag0nl0rd · 2008-02-06 23:54:44

For storing passwords, I'm using "pwsafe" http://nsd.dyndns.org/pwsafe/
It's just in CLI, it doesn't show the username/password on the screen, if you don't tell explicitly. You can just insert those with 2x middle click on the mouse in the right fields I like that feature. Stores everything in one file ~/.pwsafe.dat. I just don't know, how strong the encryption is.

finferflu · 2008-02-06 23:59:05

I actually use Vim to encrypt simple text files. I'm not a security expert, but it seems "safe". I don't know how it can compare to gnupg or truecrypt, but I just find it more practical to actually access the file using a password instead of creating a new unencrypted file (which you might even forget to delete after usage).

Dusty · 2008-02-07 00:00:16

thayer wrote:

alleviate my paranoia of nunchuk-wielding squirrels.

Its Xentac!!!!!

Dusty

dyscoria · 2008-02-07 01:23:52

drag0nl0rd wrote:

For storing passwords, I'm using "pwsafe" http://nsd.dyndns.org/pwsafe/
It's just in CLI, it doesn't show the username/password on the screen, if you don't tell explicitly. You can just insert those with 2x middle click on the mouse in the right fields I like that feature. Stores everything in one file ~/.pwsafe.dat. I just don't know, how strong the encryption is.

+1 for pwsafe! I think encryption is fairly strong to be honest. If I remember right, it uses AES encryption. pwsafe is about as light as it gets for dependencies aswell.

Last edited by Jamie (2008-02-07 01:42:45)

nogoma · 2008-02-07 14:11:15

I also use pwsafe; as an added benefit, I believe it uses a file format that is also readable by some windows programs. Of course, i've never used that feature, but it's nice to know it's there.

kensai · 2008-02-07 15:55:51

thayer wrote:

...alleviate my paranoia of nunchuk-wielding squirrels.

Well, I have seen nunchuks built of squirrels, so be afraid, be very afraid.

DonVla · 2008-02-07 18:43:21

my password storage script with gpg:

#!/bin/bash

##########################################
KEY_RECIPIENT_NAME="<your name for gpg>"
PASSWD_FILE=~/.<your gpg encrypted file>.gpg
PASSWD_FILE_UNENCRYPTED=~/.<your gpg unencryptesd file>

##########################################
GPG_CMD="/usr/bin/gpg2"
EDITOR="nano"

##########################################
# 1
#TEMPFILE=~/.<your tmp file>.tmp


# create our tempfile for our temporary password storage/ better use mkfifo 
# 2
#mkfifo $TEMPFILE && chmod 600 $TEMPFILE

# we have to make sure that we delete our tempfile whatever way we exit
# 3
#trap "wipe -f $TEMPFILE" 0 1 2 5 9 15

# prompt the user for the password
# 4
#dialog --backtitle "Password Locker" --title "Master Password" --clear --passwordbox "Enter the Password Locker master password." 10 51 2> $TEMPFILE &

# decrypt the password list
# 5
#$GPG_CMD -d -r "$KEY_RECIPIENT_NAME" -o $PASSWD_FILE_UNENCRYPTED --passphrase-file $TEMPFILE $PASSWD_FILE &> /dev/null
$GPG_CMD -d -r "$KEY_RECIPIENT_NAME" -o $PASSWD_FILE_UNENCRYPTED $PASSWD_FILE &> /dev/null
RETVAL=$?

# if decryption succeeded, open the $PASSWD_FILE in $EDITOR
# and then re-encrypt it after $EDITOR closes
case $RETVAL in 
    0)
    rm $PASSWD_FILE;
    chmod 600 $PASSWD_FILE_UNENCRYPTED
    $EDITOR $PASSWD_FILE_UNENCRYPTED 2> /dev/null;
    if $GPG_CMD -e -r "$KEY_RECIPIENT_NAME" -o $PASSWD_FILE $PASSWD_FILE_UNENCRYPTED &> /dev/null; then
        shred -v -n 35 -z $PASSWD_FILE_UNENCRYPTED && wipe -f $PASSWD_FILE_UNENCRYPTED;
        chmod 600 $PASSWD_FILE
    else
        echo "gpg failed to encrypt your password file! Please fix the problem manually!";
           exit 1;
    fi
#    clear
    ;;
    2)
    echo -e "\tEnter right password, stoopid!\n"
    ;;
esac

for use with gpg1 uncomment/comment the lines after numbers 1 to 5.
gpg2 has its own password prompt, so dialog etc is no longer needed.
as you see it uses shred, wipe and an editor of your choice.
i use nano, because vim has the .swp files which maybe a supplemental risk.

hope this helps.

vlad

fflarex · 2008-02-07 19:53:29

I just have everything in a plain old text file. I don't bother with any special program since my entire hard drive is encrypted and fairly safe from any potential attacker (and I keep my computer off when I'm not sitting at it).

However, back when I didn't have everything encrypted I still just used a text file and then encrypted that with truecrypt. By the way, makepasswd is an excellent program for generating secure passwords. I used to use the same password for everything and keep it in my head, but I think makepasswd+text file is a more secure solution, despite having broken the golden rule of never writing down your passwords anywhere. Although I also don't have much of a need to sign in to anything at other computers (which would mean I would need to memorize them).

Last edited by fflarex (2008-02-07 19:58:11)

Oxyd · 2008-02-07 20:52:17

What about VIM? The ':X' command will allow you to encrypt the file. Don't know how strong the encryption is, thought.

MrWeatherbee · 2008-02-07 20:54:13

DonVla wrote:

my password storage script with gpg:

<snip other code>
shred -v -n 35 -z $PASSWD_FILE_UNENCRYPTED && wipe -f $PASSWD_FILE_UNENCRYPTED;
<snip other code>

Since I suppose you chained 'shred' + 'wipe' in response to the fact that the original file is left behind by the 'shred' command you used (though its contents are overwritten / shredded), an alternative might be picking one command and following through with it. For example, sticking with just the 'shred' command, add the '-u' option:

shred -v -n 35 -z -u $PASSWD_FILE_UNENCRYPTED

That line shreds the contents then proceeds to a secondary process of removing the file as shown in the ouput below:

shred: /opt/test.txt: pass 1/36 (random)...
<snip output>
shred: /opt/test.txt: pass 36/36 (000000)...
shred: /opt/test.txt: removing
shred: /opt/test.txt: renamed to /opt/00000000
shred: /opt/00000000: renamed to /opt/0000000
shred: /opt/0000000: renamed to /opt/000000
shred: /opt/000000: renamed to /opt/00000
shred: /opt/00000: renamed to /opt/0000
shred: /opt/0000: renamed to /opt/000
shred: /opt/000: renamed to /opt/00
shred: /opt/00: renamed to /opt/0
shred: /opt/test.txt: removed

Important: don't get too cozy with secure deletion utilities. Every one of the author's of such utilities warns of their usage with journaling file systems. Here is one example of how to simply expose the weakness on ReiserFS:

cd /opt

touch test.txt; echo "0123456789shrednorwipeworkonjournalingfilesystems" > test.txt

shred -v -n 35 -z -u /opt/test.txt

strings /dev/mapper/vg02-lv02 | grep '0123456789shrednorwipeworkonjournalingfilesystems'
0123456789shrednorwipeworkonjournalingfilesystems

While that test is more academic than anything else, other tools are available that don't require having prior knowledge of the file's contents. Foremost is one such tool, and I have used it with success in recovering "wiped" files from my own HDs (just testing).

Everyone has their own needs when it comes to security / privacy, but if you're going to 'shred' + 'wipe' a file when it really does no more than what could be accomplished with an 'rm' command, and if you really need the level of security that such an action implies, then maybe some other methodology is in order.

andrewy · 2008-02-08 02:54:04

I use a gpg script similar to DonVia's. The encryption is good and I've used it for several years without any trouble. This should go without saying, but make sure to backup both the encrypted data and your gpg key, or you'll be in a nasty situation when your hdd fails.

DonVla · 2008-02-08 17:26:17

hi MrWeatherbee,

MrWeatherbee wrote:

Since I suppose you chained 'shred' + 'wipe' in response to the fact that the original file is left behind by the 'shred' command you used (though its contents are overwritten / shredded), an alternative might be picking one command and following through with it. For example, sticking with just the 'shred' command, add the '-u' option:
shred -v -n 35 -z -u $PASSWD_FILE_UNENCRYPTED

yes, i missed this one.

Important: don't get too cozy with secure deletion utilities. Every one of the author's of such utilities warns of their usage with journaling file systems. Here is one example of how to simply expose the weakness on ReiserFS:
cd /opt
touch test.txt; echo "0123456789shrednorwipeworkonjournalingfilesystems" > test.txt
shred -v -n 35 -z -u /opt/test.txt
strings /dev/mapper/vg02-lv02 | grep '0123456789shrednorwipeworkonjournalingfilesystems'
0123456789shrednorwipeworkonjournalingfilesystems
While that test is more academic than anything else, other tools are available that don't require having prior knowledge of the file's contents. Foremost is one such tool, and I have used it with success in recovering "wiped" files from my own HDs (just testing).

really? i thought shred would overwrite the blocks on the hd which formerly consisted the file. so the file isn't existent at all. since i didn't made much thoughts about this stuff. maybe i'm wrong. (i don't even have a /dev/mapper/vg... though i'm using reiserfs)

Everyone has their own needs when it comes to security / privacy, but if you're going to 'shred' + 'wipe' a file when it really does no more than what could be accomplished with an 'rm' command, and if you really need the level of security that such an action implies, then maybe some other methodology is in order.

like which or what do you recommend?

vlad

tesjo · 2008-02-08 18:15:54

I also prefer an encrypted text file using gnupg. And for simple and safe access (no temporary files written to disk) I like either gnupg.vim for vim or easypg for emacs.

DonVla · 2008-02-08 18:43:38

gnupg.vim sounds good, but i cannot get it working.
vlad

MrWeatherbee · 2008-02-08 19:44:38

DonVla wrote:

MrWeatherbee wrote:
Important: don't get too cozy with secure deletion utilities. Every one of the author's of such utilities warns of their usage with journaling file systems. Here is one example of how to simply expose the weakness on ReiserFS:
<snip>
While that test is more academic than anything else, other tools are available that don't require having prior knowledge of the file's contents. Foremost is one such tool, and I have used it with success in recovering "wiped" files from my own HDs (just testing).
really? i thought shred would overwrite the blocks on the hd which formerly consisted the file. so the file isn't existent at all. since i didn't made much thoughts about this stuff. maybe i'm wrong. (i don't even have a /dev/mapper/vg... though i'm using reiserfs)

Wipe, shred, srm (part of the secure delete toolkit) and similar tools all fail when used on journaling file systems (this may be dependent on what journaling mode is set on the filesystem). By default, ReiserFS (and ext3) are set to "data=ordered" mode, and that is what I have tested on ReiserFS. The 'shred' man page specifically states that for ext3, "data=ordered" should allow 'shred' to perform as expected on non-journaling filesystems. Wipe does not try to be so specific:

wipe man page wrote:

Wiping over NFS or over a journalling filesystem (ReiserFS etc.) will most probably not work.

I only tested on ReiserFS in default mode (data=ordered), and I could recover files using 'foremost' as well as recover the contents of files using the much simpler 'strings' command (see my example from above). By the way, I am sorry to have confused you, but on my system '/opt' = '/dev/mapper/vg02-lv02' because I am using LVM on that drive. Also, the main reason I chose '/opt' (though any partition should do) is that on my system (and I suspect it is true for most Arch users who have a separate '/opt' partition) I have the least number of files there, thus allowing the 'strings' command to sift through fewer files.

Since "data=ordered" mode causes failure on ReiserFS and because 'shred' is the only such tool I'm aware claiming "data=ordered" mode should work with ext3, I would want to get clarification or perform my own tests to see if that were indeed the case. I don't use ext3, so I'll leave that up to somebody else to confirm.

Of the tools I tested, running 'sfill' (with specific options) after deleting the files was the only way I was prevented from recovering the files with 'foremost'. 'Sfill' essentially overwrites all the freespace. However, it is impractical to do this often as it takes quite a while depending on the size of the volume it is processing.

DonVla wrote:

MrWeatherbee wrote:
Everyone has their own needs when it comes to security / privacy, but if you're going to 'shred' + 'wipe' a file when it really does no more than what could be accomplished with an 'rm' command, and if you really need the level of security that such an action implies, then maybe some other methodology is in order.
like which or what do you recommend?

Well, as I said, that all depends on what it is you are trying to secure and who it is that you're trying to prevent from getting at it. I only ran the secure-deletion utility tests because I had some time to do it and because there was a lot of conflicting information about exactly what worked and what didn't. I don't have anything "007" top-secret to hide however, just your usual banking and financial info. But, I still prefer to keep those types of documents on an encrypted volume (Truecrypt) since I already know that the GPG-type solutions have risks such as the ones being discussed here. And even without the testing, anything that involves leaving behind or creating a document in plain text during the encryption / decryption process seems wrong-headed from the start and should only be used when no other means are available.

Just my opinion, of course, and as you have seen in this thread (and in other similar threads where the same people usually chime-in ), everyone has his threshold of what is acceptable. In some cases, decisions were made knowing what the trade-offs were, and in some cases, others didn't understand that what they were doing was less secure than originally thought. As long as you are well-informed, the decision is easier to make for your own purposes.

tesjo · 2008-02-08 20:20:16

vlad,

I just downloaded the newest version and it seems to work. If your problem is that it ask for recipients you can set it to use symmetric encryption by default. Just add
let g:GPGPreferSymmetric=1
where the variable are described near the top of gnupg.vim. Then you can open a new document with extension .gpg and when you save it will ask for a passphrase. When you revisit the file it will ask for the passphrase to open and then to save.

thayer · 2008-02-18 02:09:42

cactus wrote:

maybe a truecrypt (or encrypted loopback) encrypted file?
you can mount and unmount it as needed, store notes, passwords, whatever inside it, and back it up as a whole file without compromising the security.
When mounted, it is also accessible from the command line.
truecrypt is kind of neat, since it can be used cross platform, and you can enabled the plausible deniability mode, where there is a hidden container inside the container.

I just wanted to follow up and say that truecrypt is perfect for what I need. I've updated the Truecrypt wiki with instructions on using truecrypt as a virtual filesystem.

Thanks cactus

steve___ · 2008-05-27 17:37:16

For those using pwsafe, how does one line wrap text in the notes?

-steve

Arch Linux

#1 2008-02-06 20:12:04

How to best store sensitive information without a password manager?

#2 2008-02-06 20:21:18

Re: How to best store sensitive information without a password manager?

#3 2008-02-06 21:09:04

Re: How to best store sensitive information without a password manager?

#4 2008-02-06 23:07:46

Re: How to best store sensitive information without a password manager?

#5 2008-02-06 23:54:44

Re: How to best store sensitive information without a password manager?

#6 2008-02-06 23:59:05

Re: How to best store sensitive information without a password manager?

#7 2008-02-07 00:00:16

Re: How to best store sensitive information without a password manager?

#8 2008-02-07 01:23:52

Re: How to best store sensitive information without a password manager?

#9 2008-02-07 14:11:15

Re: How to best store sensitive information without a password manager?

#10 2008-02-07 15:55:51

Re: How to best store sensitive information without a password manager?

#11 2008-02-07 18:43:21

Re: How to best store sensitive information without a password manager?

#12 2008-02-07 19:53:29

Re: How to best store sensitive information without a password manager?

#13 2008-02-07 20:52:17

Re: How to best store sensitive information without a password manager?

#14 2008-02-07 20:54:13

Re: How to best store sensitive information without a password manager?

#15 2008-02-08 02:54:04

Re: How to best store sensitive information without a password manager?

#16 2008-02-08 17:26:17

Re: How to best store sensitive information without a password manager?

#17 2008-02-08 18:15:54

Re: How to best store sensitive information without a password manager?

#18 2008-02-08 18:43:38

Re: How to best store sensitive information without a password manager?

#19 2008-02-08 19:44:38

Re: How to best store sensitive information without a password manager?

#20 2008-02-08 20:20:16

Re: How to best store sensitive information without a password manager?

#21 2008-02-18 02:09:42

Re: How to best store sensitive information without a password manager?

#22 2008-05-27 17:37:16

Re: How to best store sensitive information without a password manager?

Board footer