borgbackup
Show warning on every access to an unencrypted repo?
Due to being a dumb dumb, I've had an unencrypted repo for YEARS because my key had an empty password.
I only found out about it because I was restoring from a new machine and this message came up:
Warning: Attempting to access a previously unknown unencrypted repository!
Two problems:
- This message only shows once on a given machine.
- It doesn't say which of two reasons it's "unencrypted". I did a
borg infoand saw that my repo was encrypted, so I almost shrugged it off as a bug it until a redditor mentioned I might have an empty passphrase.
Better would be for this sort of behavior, every access.
$ borg info server:repo
Warning: Repo is unencrypted (encryption=none set)
or
$ borg info server:repo
Warning: Repo is unencrypted (empty key passphrase)
People with a known unencrypted repo can set an env var to shut it up.
I know it's not terribly impressive that I let this go unnoticed, but it was silent and there will be other people hanging out with me on this part of the bell curve :)
Technically, an empty passphrase on an encrypted repo does not mean the repo is unencrypted - it still is fully AES encrypted with a random encryption key.
But, if an attacker can access the borg key, the AES key won't be protected if there is an empty passphrase on it (similar also for a trivial-to-guess passphrase), so that would make it somehow equivalent to unencrypted from a security perspective. IIRC borg has some places where it considers it from that perspective.
Access to the borg key:
- repokey mode: the key is stored in the repo config, inside the repository. that could be e.g. on a remote server or on a USB disk or whereever you have your repository.
- keyfile mode: the key is stored on the client, in home directory
About borg info: will have to check the code if that can be changed easily.
borg could also in general emit a warning if the passphrase is empty. But, if intentional, that could be also annoying, especially if the warning also sets the return code to warning (rc != 0).
borg could also in general emit a warning if the passphrase is empty. But, if intentional, that could be also annoying, especially if the warning also sets the return code to warning (rc != 0).
I agree that this would be very annoying. None of my Borg repos use passphrases - fully intentional, because all my devices, including external storage, are full-disk encrypted with LUKS/dm-crypt anyway. For local repos (i.e. stored on external media) I use repokey (I was even thinking about authenticated after the release of Borg 1.1, but decided against it), for remote repos (i.e. stored in the cloud) I use keyfile (which I backup separately of course). Forcing a (possibly weak) passphrase doesn't improve security here, especially because some of my backups run unattended, thus requiring me to store the passphrase on disk, which completely defies the purpose.
Adding a note to info to report an empty passphrase (again, not as a warning) might be a good addition nevertheless (e.g. Encrypted: Yes (key file, empty passphrase)).
On a related topic: WDYT about officially deprecating (currently it's just discouraged, but still supported) unencrypted+unauthenticated (i.e. init -e none) repos and removing that option with Borg 2? People need to use transfer (we need to rechunk?) anyway, so this might be the best time for it. If you agree, it might make sense to add a warning to info about that deprecation (just info and keeping rc=0 though).
What does allowing an empty passphrase accomplish when --encryption none is available? Really seems to allow for a false sense of security.
For automated backups, I will have the passphrase on the source system's disk because I figure, if they can see that, they're in there anyway and can see all the source files too.
You can check borg-init(1) to learn more about encryption modes. Also see Thomas' answer from last week: Even when using an empty passphrase with repokey or keyfile modes, data is still encrypted.
none mode is discouraged because it allows for malicious tampering with the repo. Since Borg 1.1 there's authenticated mode as an alternative. However, using repokey mode with an empty passphrase has the advantage of allowing for borg key change-passphrase, i.e. adding a password later.
If you use repokey mode and store the passphrase on the source system's disk (but only then!), you usually (depends on the passphrase strength; and whether you consider the repo threatened, see below) get a lower level of security than with keyfile mode and an empty passphrase. Using keyfile mode is always a valid use case, no matter with an empty or non-empty passphrase. However, using keyfile with the passphrase stored on the source system's disk (again, only then!) generally doesn't increase security at all when compared with an empty passphrase.
You can think of repokey and keyfile modes as if they always require two keys: One is a randomly generated key, and the other is the passphrase. If you store both at the same place (like with keyfile and the passphrase stored on the source system's disk) you don't get any security benefit from the second one - it's as if you only have one. If you consider the place where you store your repo threatened, you must consider the repokey mode key gone, too, so you really need that passphrase. However, if one uses full disk encryption (e.g. with LUKS/dm-crypt), the repokey mode key is safe again, making the passphrase optional.
That's why there are very valid use cases for encrypted repos with empty passphrases: keyfile with an empty passphrase is always valid, and repokey with an empty passphrase can be, too, depending on the circumstances.
However, using repokey mode with an empty passphrase has the advantage of allowing for borg key change-passphrase, i.e. adding a password later.
Good idea, maybe we should mention that in the docs.