Backup Settings (+ secret key) not being backed up
hija opened this issue · comments
Due to the fact that we exclude the backup directory the backup settings nor the secret key get backuped. For me this is unexpected behaviour, because...
- After a restore the box disables/changes backup settings
- After a restore the secret key changes without explicit information, thus I assume that lots of users store invalid secret keys without knowing
Proposed change: Exclude only the backup itself from backup, but not the settings nor the secret key.
You should checkout the Moving to a New Box / Testing Backups guide at https://mailinabox.email/maintenance.html
As a side note, there is no point in encrypting the backups if you are going to store the encryption key along with the backup files.
I have experienced the same surprise as @hija , but we both assumed that the backup mechanism is a proxy for moving your user data to a new installation. AFAICT the backup design did not envision a usage that preserves and restores more of the configuration -- it assumes you are restoring to the very installation that created the backup. It's definitely a grey area though, given the instructions for the recent (high-friction for me) upgrade to Ubuntu 22.04.
I see as the greatest danger that people are assuming their MIAB is doing backups as before and that it uses the same encryption key. Then - in case of disaster (when you cannot test your backup before) - the backup is missing and/or the encryption key is missing.
@jvolkenant regarding the encryption key storage in the backup: I would of course encrypt the key as well. I would not put it unencrypted at the backup place. That would make the whole encryption useless, as you already mentioned :)
@JoshData What is your take on this? Would you appreciate a PR for this or do you see a reason why not to store the encryption key + backup settings?
I strongly oppose the idea of storing the BackupKey with the Backup!
This is the same as doing unencrypted Backups, a bad idea unless you store the backups on the box itself, but then it doesn't count as backup after all.
Encrypting the key with another key just moves the 'secret to keep at a safe place' up one step, since losing this second key means losing the first key means losing the backup. More complexity also means higher risk of errors in the process. And keeping the key separate and secure still remains the duty of the admin.
Also, in the setup guide it states explicitly:
However you store your backups, you must copy the encryption password file described on the Backup Status screen somewhere safe! Backups cannot be decrypted without the backup key!
So, thanks to Josh for having the setup secure by default.
As for productive feedback, here is how I handle this:
After the installation (probably 6 years ago) I copied the encryption key file into a safe and (with another password) encrypted personal storage (Seafile running at home). Also, since losing the encryption key would render my backups useless, I copied the content of the file into my password manager, which is encrypted too. (Was lastpasss then, is Bitwarden now.)
Now I feel safe regarding the encryption key. But a backup, that is not frequently tested might be useless and broken, you just don't know yet. So a good practice is to start up a new VPS aside the running one and recreate your MIAB with a restore of your backup. Basically do a migration to a new box once in a while. Just make sure to attach the old IP to the new box, Mailservers build up credibility on their IP for not sending Spam and also redoing DNS and glue records just s**** :)
This way you know your backups work and also you know that in case of a failure you are able to restore the mailserver for yourself and every other user you might have in under an hour.
Once you have lots of friends and family relying on the 24/7 availability of your box, losing incoming mail because the box is offline long enough that other mailservers give up retrying is just not something you would want to experience.
I told all the friends and family how nice it is to run this stuff your self, not rely on data collecting vendors, having the system down would just have them go back to the easy to use googles/yahoos/... out there.
//Sorry for the long rant, I hope there is something productive to take away, thanks.
I strongly oppose the idea of storing the BackupKey with the Backup!
This is the same as doing unencrypted Backups, a bad idea unless you store the backups on the box itself, but then it doesn't count as backup after all.
As mentioned earlier, the backup key would be encrypted as well. It is not stored as plaintext alongside the backup. If we do not do this the BackupKey changes if you restore a backup to a MIAB and I do not think that this is expected behavior. I do not see why this should pose a security risk.
I realize, we had misunderstood each other.
I was off the impression, you would encrypt the key in an additional step, with the goal of easy retrieval after a loss of the original box. I think now, that your goal was only to have the key be overwritten during restore with the old key, so the restored box would be able to use the same key, instead of the randomly generated one it has after a fresh install.
Sorry for making a fuss without actually getting your point.
That is actually a good point. I still would not have the backup process do this in an automated fashion, but there should maybe be reminder during the restore process, something like "if you are restoring to a new box. Don't forget to copy your secret key over the randomly created one on the new miab".
Or maybe the process could ask the user if the supplied secret key is different from the one found on the box. Something like "warning: this backup comes from another box (different encryption key). If you are doing a move from one machine to a new one or restoring your backup to a new box, please overwrite the encryption key on this box with the one used to create the backup".
But since it states in the maintenance guide, that for a restore one should copy the secret key to the new box it might suffice to make that part of the documentation clearer, stating that the key should not merely be copied over but replace the corresponding file on the new box.
Maybe a first step could be this textual clarification in documentation as a small pull request?