26

I found a very interesting CLI password manager called pass. To use it, you generate a GPG2 key pair, and use the tool to help you store passwords in gpg2 encrypted files.

To encrypt the files (add a new password), it uses the public key.

To decrypt the files (retrieve a stored password), it uses the private key, which requires a password.

This works great.

Now that the tool is storing all my passwords, I want to backup all this data so that if my computer crashes, I won't be locked out of all my online accounts.

The tool integrates nicely with git, so I was able to easily push the .gpg files to my private git repo on a different computer. From what I understand, these files are useless without the private key to decrypt them.

My question is this: how do I backup the private and public keys in a safe way, so that I can restore the "database" on another machine if the need arises? Can I just store both the public and private keys in my git repo, and import them on a different machine at a later time? Or is it considered unsafe practice to store a private key in a private, local git repo? The git repo requires a password to access. The private key is encrypted, and requires a password to open - does that make it safe to store?

11

Storing a PGP private key in a revision control system does not, in and of itself, pose any significant security issues. Storing the private key in a local, private (unpublished) git repository should have no significant security implications versus storing the private key on the same computer but outside of any git repository.

The only issue I can think of that comes from storing the private key in a version-controlled manner is that unless you can somehow destroy the older revisions, key passphrase changes buy you far less protection than they otherwise might.

What can come with its own set of security implications is storing a private key in such a way that someone else might be able to get access to the key file. In such a situation, all that stands between an attacker and your key is the strength of its passphrase.

Recognizing that storage security isn't perfect, and even more so in the modern environment where people regularly back up to cloud services (which literally translated means "someone else's computer"), we usually protect our secret keys with passphrases. I trust that, even if you are running for example gpg-agent, you are doing the same.

The bottom line is that, as long as your passphrase is good, even storing a copy of the encrypted key file on someone else's computer should be relatively safe.

However, that's a pretty big if: most peoples' passwords or passphrases are rather lousy as far as computerized attempts at cracking them go. GnuPG goes to quite some length to try to work as well as it can with what you give it, but for solid data protection, you need a good passphrase, and you need to set it before importing the private key into the git repository. After the key has been imported, an attacker could in principle attack any version of it, and if they have reason to believe that a particular revision has a lower-quality passphrase will likely go for that. For that reason, make sure that you pick the passphrase with care. I have written up a small primer on how to handle passwords, including suggestions on how to choose passwords or passphrases that you need to be able to remember, which you may find useful.

| improve this answer | |
6

I've been considering a similar setup recently. Before tackling your question, let me point out what bothers me about it. This is explained at great length here. In short- when Pass calls GPG, it performs unnecessary asymmetric (RSA/EC) crypto under the hood. Unnecessary- because there is no untrusted party here.

This is annoying because asymmetric crypto is less future-proof than symmetric crypto. E.g., asymmetric crypto of today is broken by sufficiently large quantum computers, that do not exist, yet. More generally, asymmetric crypto relies of "math problems" we do not know how to solve, much more so than symmetric crypto.

To mitigate this weakness, the least you could do is to keep your GPG public key used with Pass private as well, because for instance the (potential) quantum attack needs this public key: see here.

On to your actual question, it is unclear whether you intend to store the git repo (with the passwords) publicly or privately. If you want to keep it private, you can pretty much do what you want, and reduce the security of the GPG private key to that of the medium where you back up the repo. However, that might become a chicken and egg problem: if the repo is private, how do you get it back in case of a crash? In other words, in case of a "bad crash", there must be something you retrieve first. So you might want to keep the git repo private, but backup the GPG key in such a way that you can retrieve first, independently of anything else.

Offline back up solutions are numerous, lawyers, basements, etc. see here. But basements aren't for everyone, so let me suggest an online solution:

  • Create a super strong passphrase that is not meant to be typed for years. Suggestion: Long, memorable misspelling of a phrase that has some personal significance, or from a book that won't run out of copies if you need to look it up.

  • Create a tarball with your exported GPG secret key, and maybe your SSH credentials.

  • Encrypt it symmetrically with your passphrase: gpg --symmetric --armor.

  • Create a free git hosting account.

  • Create a public repository, that can be cloned without credentials.

  • Put the encrypted&armored tar ball in there.

To retrieve it after a "bad crash":

  • Boot a live USB stick.

  • Clone public repo.

  • gpg --decrypt.

The symmetric passphrase will be your main protection against the zombies. People sometimes do not give you, or the anonymous reader, the benefit of the doubt when it comes to choosing passphrases. But with a good passphrase, symmetric crypto should be solid.

When you export your GPG private key, it will be encrypted with a passphrase of its own. Recent versions of GPG won't allow an unencrypted export. You might use your "regular" GPG passphrase here. Just remember that in the event of a crash, you will need both passphrases to get to your GPG private key.

| improve this answer | |
4

Another option I use is: Print your key on paper.

The details are in the linked answer. The big advantages are: You can easily store it wherever you want and you can check if it is still likely in good shape by just looking at it. But the biggest advantage is: No one can hack it without actually physically being in the place where you store your backup and taking it.

| improve this answer | |
  • As far as I can see, paper has no advantage over removable media in this case, and the disadvantage that if you need to recover the key, you have to type in all the gibberish for the key. – MAP Aug 10 '16 at 4:17
  • The advantage is, it's far more durable and you can check if it is still readable with your own eyes without a computer. If I'd have a dollar for every floppy disk, CD or DVD I used which now has unrecoverable data errors, I could go on holliday with that money. You don't have to type anything! PaperBack prints it as 2D codes with error correction added. You just scan or photograph it and the program turns it back into whatever you gave it to print before. – Josef says Reinstate Monica Aug 10 '16 at 5:50
  • Assuming, of course, that you still have the technology to do that. – MAP Aug 10 '16 at 5:54
  • Well, the probability that I easily can get a Windows VM or Linux with Wine with a copy of that Open-Source software in 20 years is in my opinion much higher than the probability that I can get the hardware to read a floppy disk/CD/DVD. Just assume I did that 1990. I can now even run software from back then in my browser. But good luck trying to get hardware that allows you to read a 5 1/4 inch floppy with your modern PC. – Josef says Reinstate Monica Aug 10 '16 at 6:03
2

Another answer to this is "offline", i.e. storing it in some place that is secure and not connected to any computer. I keep a full, unencrypted copy of all my keys on a floppy disk (I've been doing it this way for a long time, now it's a habit) in the safety deposit box at the bank. The reason I keep them unencrypted on the media at the bank is that one potential scenario for "losing" the key is forgetting the pass phrase (my pass phrases tend to have lots of weird punctuation and spellings, and forgetting just one of those makes it unusable). I have never had to resort to getting it back from that copy, but I plan for the worst.

Additionally, there's a key revocation on the media and a note instructing my heirs on what to do with it, in the case I'm no longer available.

| improve this answer | |
  • If you back up the master signing private key, can't that be used to generate a revocation certificate? In what scenario is it useful to back up the revocation certificate? – Matei David Aug 8 '16 at 3:40
  • Ah yes, but you must understand that I can not be certain of how computer-savvy the person executing the request will be (note that it's not me who will use it, but "my heirs"). So having the revocation already generated and instructions of "just send an email with this file attached" is less likely to be mismanaged. – MAP Aug 8 '16 at 3:44
  • @MateiDavid Generating a revocation certificate when you initially create the key pair, and storing that revocation certificate, allows you to revoke the key if the key becomes unavailable to you. There are valid scenarios where this can happen. Of course, you have to guard the revocation certificate very well, because anyone who gets their hands on it can publish it thus revoking your key pair. I'm not really sure how a revocation certificate even applies to the OP's situation, though. – a CVn Aug 8 '16 at 17:07
  • Yes, we've gone down a rat hole. I apologize, my mention of the revocation certificate was only for completeness in the description of the steps I take, and didn't have anything to do with the original question. – MAP Aug 10 '16 at 4:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.