Duplicity

Encryped passwords/phrases

Asked by Christoph Löhr

Is there an option or feature, where passwords and/or pass-phrases for gpg or storage-backends, can be stores encrypted.
Is there any planned feature to add this support, this could be very useful for running automated encrypted backups.

Could this be a part of the installation itself or more like an add on ?

Kind Regards

Chrit

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
edso
Solved:
Last query:
Last reply:
Revision history for this message
edso (ed.so) said : 		#1

On 18.04.2016 17:27, Christoph Löhr wrote:
> New question #291346 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/291346
>
> Is there an option or feature, where passwords and/or pass-phrases for gpg or storage-backends, can be stores encrypted.
> Is there any planned feature to add this support, this could be very useful for running automated encrypted backups.
>
> Could this be a part of the installation itself or more like an add on ?
>

having secrets (eg. passphrases) encrypted/obfuscated makes no sense as the decryption has to happen on the same machine anyway so the secret can be used in gpg which expects it to be plain.

the standard solution for what you ask is gpg-agent, which keeps secrets obfuscated within memory for a configurable time span. essentially you have to
1. configure gpg-agent to cache the passphrases for a really long time eg. https://superuser.com/questions/624343/keep-gnupg-credentials-cached-for-entire-user-session
2. run duplicity (or gpg against the same key used in duplicity) once as the user it is run later in cron and enter the secrets for gpg-agent to cache them

of course this must be repeated in case you reboot the machine at some point.

..ede

Revision history for this message
Christoph Löhr (chrit) said : 		#2

Hi,

this is not the part of how i want to use it. There are some considerations, in special that the machines should to automated backups, without user interactions or agents running. In addition of course without clear text passwords.

Your answer sounds, like, build your own wrapper around the duplicity to fix this issue with the passwords.

Chrit

Revision history for this message
Best edso (ed.so) said : 		#3

On 19.04.2016 09:58, Christoph Löhr wrote:
> Question #291346 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/291346
>
> Status: Answered => Open
>
> Christoph Löhr is still having a problem:
> Hi,
>
> this is not the part of how i want to use it. There are some
> considerations, in special that the machines should to automated
> backups, without user interactions or agents running. In addition of
> course without clear text passwords.

without interaction you would use usually passphraseless machine key and additionally encrypt against your own or a global public key in general (yes, you can encrypt against multiple keys w/ duplicity).

> Your answer sounds, like, build your own wrapper around the duplicity to
> fix this issue with the passwords.

to your ears may be, but i know what i mean and _that is_:

having the secret on the box means the hacker has it as well. obfuscating it simply makes retrieving it little more difficult. you provide the means to decode it on the same box, that's inherently insecure.

what do want to achieve anyway in the big picture? usually you want to protect your data. you use duplicity to dump your backups on inherently insecure space because you trust gpg's encryption is sufficiently secure for a third party not to break it.

so if an attacker already has access to your box, as the user that runs duplicity, he also has access to the data you want to backup. additionally he has access to the space you dump your backups to and can modify the data there and also read your old backups. essentially that box and it's backup space are lost.
to my knowledge the best way to work around that vector is to have passive copy of your backup repo, only copying new files, never touch existing ones. the challenge after the armageddon will be to find the latest clean backup of course.

in conclusion: use passphraseless keys for automation w/o human interaction with gpg, that's why the option is there.

..ede/duply.net

Revision history for this message
Christoph Löhr (chrit) said : 		#4

Thanks edso, that solved my question.