How to best store sensitive information without a password manager?

Question

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)

Answer 1

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.