barebones recovery with encrypted repositories

[anarcat]

I am using the repokey encryption for an offsite server. That is because I want to be able to do "barebones" recovery, that is: I want to be able to recover backups with only what is on the backup server. This means I need to store the key on the server, and repokey does that.

But this means that I need to specify BORG_PASSPHRASE on the backup client(s). So far so good, even though I don't like the idea of hardcoding the passphrase in the clear somewhere on the server. (I am aware of the BORG_PASS_COMMAND hacks, but this is just a layer of indirection: server-based automation requires some sort of cleartext access, as there's no user at the console.)

Because this is a passphrase that will be typed rarely (hopefully: just when there needs to be a full recovery in case of a catastrophe), it is likely to be forgotten. And this is where this gets problematic: a solution for this is to reuse an existing password the brain is already trained for, an existing, strong desktop login passphrase for example. While not ideal, it beats completely forgetting that passphrase. But then this makes the problem of specifying the passphrase in the clear much worse: then a precious passphrase is available in the clear.

What was suggested by @Elladan on IRC is to have multiple passphrase on the repokey encryption: that way a strong, completely random and unique password can be used on the client, while on the server the repokey would be encrypted with the well-trained password, that might be weaker but at least not accessible in the clear.

I'd be curious to hear other options for this. I have considered using the keyfile encryption with the well known passphrase, copy the keyfile to the server, but then re-encrypt the keyfile (or completely unlock it) on the client. Would that work too?

And of course, I know one can simply keep an encrypted copy of the passphrase on the server, through other mechanisms (e.g. GnuPG symmetric encryption or a password manager): I'm looking for a borg-native solutions.

thanks!

[anarcat]

possible cross references:

• Public key encryption support #672 public key crypto
• Crypto roadmap #1044 crypto roadmap

[enkore]

Store an exported copy with your human-compatible passphrase on the server as well? (That's pretty much repokey with multiple passwords, except it requires full shell access, isn't automatic and fiddly, too!).

[ThomasWaldmann]

I don't think having 1 (2) encrypted keys with 2 different passwords (1 rememberable "easy", 1 random) on the backup server is a good idea. If the weak spot is the rememberable password (assuming it is easier than a long high-random pw), then the weak password determines the security of the system.

Also, any potential pw reuse is a potential problem.

I'ld rather suggest having a long random pw and storing it in a pw manager and have that data backupped / synced otherwise.

[anarcat]

I don't think having 1 (2) encrypted keys with 2 different passwords (1 rememberable "easy", 1 random) on the backup server is a good idea. If the weak spot is the rememberable password (assuming it is easier than a long high-random pw), then the weak password determines the security of the system.

You assume too much. :) I would argue that the "memorable password" can be as strong (for all intents and purposes) as the purely random password (cf. diceware, xkcd). The key here is not that it's a "weak" password, but that it is a password currently in use elsewhere, so it is possible to remember it.

Also, any potential pw reuse is a potential problem.

Of course it is a problem... Yet I do not see how else I can remember this passphrase, if I never use it. Those are long term, seldom used backups. The only moment I will need them is likely far ahead in the future, far from when I originally setup the system.

I'ld rather suggest having a long random pw and storing it in a pw manager and have that data backupped / synced otherwise.

So how do you backup/sync the password manager? I clearly stated that was an option I discarded, because it doesn't actually fix the problem from borg's perspective, it just punts it over to the password manager:

And of course, I know one can simply keep an encrypted copy of the passphrase on the server, through other mechanisms (e.g. GnuPG symmetric encryption or a password manager): I'm looking for a borg-native solutions.

I know that some password managers are single-file, one password systems (e.g. keepass), so they might be a little easier to synchronize to the backup server. The password manager I use (pass) doesn't work like that. It's backed by my OpenPGP keys, so to backup that, i would need (1) a copy of the password database and (2) a copy of the GnuPG private keyring. The whole reason why I encrypt the backups is to, among other things, encrypt that GnuPG keyring and not store it directly on a third-party server without an extra layer of protection.

Anyways, even if I would use keepass as a password manager, I would still expect Borg to protect that password manager with borg's own encryption, even though the password manager is encrypted itself. Defense in depth.

borg should be able to backup my password manager, no? :)

Store an exported copy with your human-compatible passphrase on the server as well? (That's pretty much repokey with multiple passwords, except it requires full shell access, isn't automatic and fiddly, too!).

Again: I considered that as well. What I'm saying is that it's not a native solution, as you say this requires more than a restricted shell access to the server, so it's not portable to borg hosting providers.

Besides, storing an encrypted copy of the passphrase next to the repokey doesn't improve the security of the system in any way at all. We're just moving the target: we still have the same problem of having two passwords for, effectively, the same secret key material.

In other words, the solutions proposed as an alternative to having multiple passphrases on the repokey do not improve the security properties of the system in any way, so I don't think they're good arguments against the idea. Now, added complexity or backwards-compatibility: that I would agree could be issues. But I think it might be possible to do that effectively. Note that there is prior art for this: LUKS-encrypted partitions have multiple "slots" to store and rotate passwords. We could have multiple entries in a similar fashion...

Thanks for the quick feedback! This certainly provide short-term alternatives to the problem that I will consider. I would still like to hear your opinion on the feasibility of using a modified keyfile approach...

[enkore]

There is no issue per se with adding multiple key slots (in dm-crypt terms) to the existing format, since these can reside under a separate key in the outer key wrapping (msgpack). I think there is an implicit length limit somewhere on the size of the final key blob.

A more important problem is that changing the passphrase with an un-aware borg version would silently discard the additional key slots. So I don't think this approach is any good. Instead,

• either bump the key version (breaking backwards compat),
• or add a second key-blob (save_key2, load_key2, second key file for keyfile mode). This works because borg doesn't rewrite the repo config (check might?).

When something like this is implemented, remember to fix the crypto as well.

[ThomasWaldmann]

@anarcat usually, if one uses a pw manager, one needs access to these passwords from multiple devices, e.g. from mobile devices (laptop, smartphone, tablet) and desktop devices (pc, ...), also sometimes rather private devices and business devices.

To practically enable that usage and not run into consistency issues on multiple devices, one needs some synchronization solution that keep the pw db in-sync on all the devices. So if you lose one device, you still have your pw db on all other devices. And if you backup all your devices, you have the pw db in multiple backups and you won't lose access to all the backup repos at the same time.

[enkore]

Thomas, this ticket is about

"barebones" recovery, that is: I want to be able to recover backups with only what is on the backup server.

[anarcat]

I think it would be fair to assume I know how password managers work and I do have multiple deployments of my password manager. It just so happen that they might all be in the same place at the same time: that is not a backup system, it's a synchronization and distribution system.

What I need from borg is backups. I know how password managers work. :)

@enkore I'm fine with bumping the key version: I think it can be in a fair, backwards-compatible way. One could introduce a new flag that's off by default that allows creation of such repokeys and then make borg support reading from those in any case. Next major release, the default can be switched and compatibility garantees are respected. Could you expand on what you mean by "fix the crypto"? Are you refering to #1044 or something more specific?

[enkore]

I wrote about key encrytion here; to summarize, there are two three issues with it:

1. It uses Encrypt-and-MAC in one of the few constellations not being outright broken (CTR mode, no padding and HMAC).
2. It reuses the same key for both AES and HMAC. Again not obviously broken in this specific constellation, but very poor practice.
3. It uses PBKDF2, and it uses comparatively weak parameters. (Using a more modern KDF than PBKDF2 #747, another issue number I know by heart ;)

[anarcat]

@enkore thanks! it seems to me this should be factored into #1044, no? :)