I wasn’t quite sure where to put this, but I thought I’d share how I store a “cold wallet” copy of my Restic password.
My passwords are usually a 512 random character string. I take that string and put it into an SVG QR code generator (vector image, you’ll see why shortly). I up the error correction level all the way, then print a few copies full page (SVG obviously scaling perfectly). I store one at home, and another at my parent’s house, inside a large book on a shelf. Can’t even tell it’s there.
Should disaster truly strike, and my house burns down, and somehow I lose access to the password-encrypted vault in my Dropbox… I scan the QR code, copy it, then paste it to my Mac using Handoff. At that point I’m ready to restore from Backblaze B2.
(Not my actual password )
I have crumpled them up, cut holes in them, drawn on them with a Sharpie, etc. With the error correction, it scans just fine. So long as QR code scanners remain available, it’s a pretty nifty way of keeping a password hard copy. Sure beats trying to OCR 512 random characters, am I right?
I have a similar approach that is slightly more complicated but offers several additional benefits.
I have a GPG public key that I use to encrypt anything that I want to backup to untrusted storage. This would include one of my restic repository passwords.
The key pair was generated on a machine without an Internet connection and stored only in a tmpfs (it never touched the disk.)
The encrypted private key is printed out as a QR code. (It takes a whole page! And yes, I’ve tested scanning it using a flatbed scanner and having a QR code scanner read it. GPG imports the private key successfully.)
I cut the randomly-generated passphrase to the private key in half. One half I ran through ssss and put a different share on each printed page. The other half I wrote by hand on each page.
Then all of the pages were geographically distributed, similar to your system. Finally, the private key was destroyed by powering down the isolated system.
So the end result is that I have N papers, and any M are required to recover the unencrypted private key (but M-1 shares will not be able to reconstruct the passphrase). 1 < M < N. Each page has:
- The same QR code of the encrypted private key.
- The same handwritten half of the passphrase.
- A different ssss share for the other half of the passphrase.
The benefits of this scheme are:
- I can arbitrarily add any amount of data to this “split backup” mechanism by encrypting using the GPG key and uploading to multiple untrusted cloud providers. (Dropbox, Google Drive, OneDrive, S3, B2, etc.)
- After the original (cleartext) data is destroyed, the only way to access this data is to obtain the required number of physical shares to reconstruct the private key.
- You need more than one of the physical shares to reconstruct the passphrase to the private key, so a malicious actor would need to obtain M pieces without me noticing.
- I can sustain the loss of N-M physical pieces while still being able to reconstruct the passphrase.
- Hand-writing part of the passphrase protects me in the case that my printer stores an image of each page; an attacker who came upon that particular printer would only have half of the passphrase and would additionally have to compromise one of the physical shares to get the handwritten other half.
- I can put the public key on Internet-connected servers and run backups from them without fear that compromise of the server will expose the private key.
Hahaha that is freaking brilliant. I love it! Now I’m going to have to play with ssss a bit.
OH… MY… GOSH… This is thorough…
I was working on a similar solution for a similar problem.
You can check it out https://github.com/renard/papersave.
- Can backup arbitrary file. However do not backup large files its primary goal was to backup ssh key (files smaller than 10k).
- Content agnostic: data is compressed and base64 encoded.
- Suitable for QR-Code, OCR or manual typing.
- Can encrypt the data using a AES-256-CBC (suitable for gpg) cipher to allow restoration over untrusted networks (especially for online QR-Code scanners).
- Only use standard a tool-chain to restore data (gpg, gzip, base64).
- Uses SHA256 checksums and CRC32 for data integrity.
CAUTION THE CODE IS STILL YOUNG
I always wanted to learn Go and this was the right project for me. Anyway any comment, suggestion are welcome.
Hope that helps.