Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I currently store my passwords in a text file encrypted using GPG -e (specifying my own public key). When I want to lookup a password I'll do something like

gpg -d passwords.gpg | grep <sitename> | less

and when I want to add a new password I'll decrypt the file, edit the file and then encrypt it again.

What are the potential risks in this strategy? Are there any security issues to doing this compared to using something like Password Safe?

share|improve this question
    
The main risk IMHO is having the machine compromised; that applies equally to both solutions considered. An attack seems easier to mount on the command-line solution (e.g. with a trojan in any of gpg/grep/less/bash/kernel, or a keylogger in hardware or software), on the other hand a malware could target the other program if it gets audience. –  fgrieu Apr 27 '12 at 3:18
    
I'm sending this over to security.se as there's more of a security considerations what-should-I-do aspect to it than pure crypto. I know the difference is hard to get sometimes. Anyway, do register there to pick up your reputation and responses (the Q will automatically appear in your account when you register) :) –  user2213 Apr 29 '12 at 13:43
add comment

migrated from crypto.stackexchange.com Apr 29 '12 at 13:43

This question came from our site for software developers, mathematicians and others interested in cryptography.

3 Answers

Your biggest problem is system compromise. If you store your key encrypted under a strong passphrase, then this is equivalent to the risk with a password manager ( in fact if this is any indication, a lot of password managers don't derive encryption keys from master passwords correctly, so you're probably better off with gpg which does). So if someone roots your system and then you unlock your key, they have all your passwords. This is the same with any password manager that runs on your system.

If you don't encrypt your gpg key though, anyone who gets access to your system, even when its off (e.g. steals it) can read your key, decrypt your file, and get your passwords. This is worse than a good password manger (e.g. lastpass, keypass, or even the OSX keychain).

Your second biggest risk is that that shell command writes tmp files to your system even if it deletes them (since deleting a file does not overwrite the data and it can be recovered with software). GPG might write temp files, grep might write temp files, less might write them. As might your shell. Moreover, since the last three of these are not meant to be secure, there is no reason why they might not decide to do that at some point in the future. On the other hand, a decent password manager would take steps to make sure it never wrote your clear text to disk. It could even only store your data in locked pages that don't get swapped to disk.

On the purely cryptographic side your max key size in gpg is probably 2048 bits. This gives you max 112 bits of security. To get something equivalent to AES256, you'd need a 15360 bit key. This is the least of your concerns, but it still is one. Password managers usually use symmetric crypto so they can use AES128 or 256.

share|improve this answer
add comment

I've used this exact technique for years. One large risk is if you forget to delete the cleartext file after your decrypt > edit > encrypt. With GPG the encrypt leaves the cleartext file in place. Worse still is if you leave that cleartext file there during an automated backup. Then you'll have to go find the backed up file(s) and delete it/them.

share|improve this answer
    
You can handle this in a couple of ways. One is to use grep and less to decrypt your file to stdout. Another is the gpg extension for vim which never writes the unencrypted file to disk. –  Kyle Butt Feb 12 '13 at 19:36
add comment

In addition to the caveats in other answers, the decrypt-edit-encrypt cycle could leave plain-text traces well after you've finished editing. Specialized password safe software and attempts by other people to securely edit files note many potential risks:

  • Editor temp/save/backup files
  • Editor recent file history, command history, cut-paste history
  • Editor or other memory written out to an unencrypted swap partition or during hibernation
  • Insecure deletion of data (not overwritten with shred(1) or similar)
  • Journalling or copy-on-write file-systems keeping "deleted" data
  • Back-ups catching data in transit
  • Clipboard not cleared or history kept
  • Screen clearing after editing
  • tmux/screen/remote desktop/x/over-shoulder security
  • SSDs have complex data handling

There's no doubt a bunch of other potential concerns. I'm still weighing them up versus the usually clunky password-safe software. The gpg-vim combination that never writes the plain-text file to disk seems promising. Alternatively, using an encrypted file system layer below the plain-text file while editing may also be enough.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.