Most secure way to save Backblaze B2 credentials

Getting Help
1

Hello,

I have setup restic to my Backblaze account and all seems to be working as it should, but I’m wondering what would be the most secure way to save my Backblaze account information and encryption password?

Currently, I have everything exported from my .bash_profile, but I’m concerned this isn’t the most secure way to do it.

Thanks!

2

Hi,

You don’t mention the environment in which you’re working, or what you’ve done to protect your .bash_profile from access by others, so what you’re doing may be adequate, but you’re right…exporting variables from a profile and leaving them exposed in your environment indefinitely is certainly not the most secure way to do it.

With the caveat that I’m not a Linux security expert, I can tell you what I’ve done. That is to set up a directory (…/restic/credentials/) which is owned by root and accessible only to root. I have files with my account credentials and repo credentials in that directory, with similar access restrictions. I then start restic via a short script, run as root, which parses my credentials files, exports the necessary variables, and builds and executes the restic command line. The theory is that only someone with superuser privileges can look at my credentials files directly or snoop on the environment of my backup process.

I’m sure that’s not the “most secure” way to do it–and no doubt other members of the forum can suggest more secure alternatives :wink:–but in my environment (a small server with a small number of trusted but non-privileged users) I think it’s sufficient.

Hope that helps.

3

Hi and thanks for the reply,

I’ve done nothing to the .bash_profile to prevent others from accessing it, but I’m generally the only one using the computer since it’s my personal home computer.

I see that there is the “password-file” option in restic. Is that only used for the encryption password, or can it also be used for account credentials?

4

Only for the encryption password as for now.

5

Transmission cli has pretty good solution to it: first you save password as plaintext, then after first run Transmission encodes it.

6

It would be nice to have support for Vault.

1 Like
7

I know this is nearly two years old, but I have a script that:

  • Takes two arguments:
    • Filespec to special 7zip file
    • Repository location
  • Sets up a ramfs
  • Extracts a predefined key:value text file from the specified 7zip archive, to the ramfs, prompting for the encryption password along the way.
  • The key:value file contains my backblaze credentials, which the script parses
  • Uses those values to launch the program
  • Tears down the ramfs

For added security, I have the encrypted 7zip on an eCryptfs volume. (Well that’s actually coincidence, 7z alone would be good enough for my needs.)

8

This might be a bit over-engineered with the 7-zip file and ramfs. You could simply export the variables from a GPG-symetrically-encrypted script and embed that in the outer script:

#!/bin/bash

data="$(GPG_TTY=`tty` gpg --no-options -d <<DATA
-----BEGIN PGP MESSAGE-----

jA0ECQMCIPlxSRIOU/Xn0mQBgvB23H+Bg0fd/BKDTTs6cXHp8oR6sjRIGYGwitG3
8z2qtQuhhJeG7gUZzMMkzeGwbwbXcA+TFDLQXG0qexlue4es0JSAw2Ckk2xYXXUP
dJsBAoR5A9ArjMHwjIrjkeflWg1r
=SzYO
-----END PGP MESSAGE-----
DATA
)" || exit 1

eval "$data"

echo "Password is $RESTIC_PASSWORD"

The encryption password for this is “testing” – try it out.

1 Like
9

That’s an elegant solution.

The only problem in my case, is that it’s not generic enough. (But it does give me an idea for an improvement.)

My script is more generic, in that 1) it can take any archive as an argument, and 2) the password can be trivially changed, without modifying the calling script.

But by extending it with your “execute a script” idea (why didn’t I think of that), it can be even more generic; I can simplify and make more generic, the main generic script; and the archived script can set any variables and invoke an arbitrary command, restic or otherwise.

The ramfs setup and teardown are both one-liners, fairly trivial, won’t swap contents to disk, and I don’t have to worry about credential bits lingering on persistent storage.

Thanks.

10

I do something similar with the password in file

export GPG_DECRYPT_CMD="gpg -q --for-your-eyes-only --no-tty --exit-on-status-write-error --batch  -d"
export RESTIC_PASSWORD=$($GPG_DECRYPT_CMD /some/path/restic_password.gpg)
11

My preferred way is to use B2 as if it was standard S3. This way you can use files and not rely on environment variables.