Passwords, credentials and environment variables

How-to
, ,
#4

I am asking how to get passwords etc stored there? I initialized a repository and storage, but the encryption password was not put on that file.

Answering to myself. duplicacy saves automatically the information (passwords, one_token, B2 keys, etc) to the keyring when you run backup for the first time and enter the information manually.

3 Likes
#5

Wanted to clarify that the env var needs to be set with export, otherwise it won’t be read by duplicacy.

DUPLICACY_GCD_TOKEN='bla' = bad
export DUPLICACY_GCD_TOKEN='bla' = good

1 Like
#6

Thanks! :+1: The OP is a wiki, feel free to edit it. :smile:

#7

is this for windows, linux, mac, all ?

#8

@gchen
no environment variable for RSA private key file path?

#9

No, the RSA private key file is passed by the -key option.

#11

not planned as an improvement? :innocent:
ENV var + preference key for RSA private key path

I noticed an egg, for “duplicacy copy -h”

-key <public key> the RSA private key to decrypt file chunks from the source storage

#14

Does Duplicacy use the storage password to encrypt credentials in the .duplicacy/keyring file? If it doesn’t then are there any other ways to protect the keyring file with strong password?

#15

The storage password itself is stored in the .duplicacy/keyring file so no, it is not used to encrypt .duplicacy/keyring.

The .duplicacy/keyring file is encrypted by the Windows Crypto API (CryptProtectData function (dpapi.h) - Win32 apps | Microsoft Docs).

#16

Maybe it’s possible to implement something like DUPLICACY_KEYRING_PASSWORD? I’m not sure if DPAPI is reliable enough to trust it with credentials for cloud storages. A strong master-password protection would be preferable.

#17

I noticed the table above does not include the environment variable for the OneDrive for Business (not OneDrive) token. I believe the correct variable is: DUPLICACY_ODB_TOKEN. For storage, it is DUPLICACY_STORAGENAME_ODB_TOKEN. Thought I’d post this since it took me a little while to figure it out!

Great backup app. Thanks for all of your work on it.

2 Likes
#19

Thanks for pinging us, OP is updated!

#20

@TheBestPessimist
RSA key passphrase DUPLICACY_RSA_PASSPHRASE DUPLICACY__RSA_PASSPHRASE rsa_passphrase

this line is missing in your start post
I added the sftp keyphrase here:

#21

I added it to the table. Could you please check that what i added is correct?

1 Like
#22

Personally I don’t like the idea of storing Google Drive token as a plain text file. Is there any way to store it safely?

#23

A post was split to a new topic: Password management in WebUI

#24

@TheBestPessimist Can/should I use a different storage password for each storage added to a repository? I am trying to back up with SFTP (local) and B2 (cloud) with -copy and --bit-identical.

#25

You can use different passwords with -copy-compatible, but not with -bit-identical, as follows from the name of the parameters.

#26

@saspus It seems that they can, even with -bit-identical. I just found this in the docs here:

-bit-identical
The -bit-identical option is used along with the -copy option and will copy the IDKey, ChunkKey and FileKey to the new storage from the old one. In this case the names of the chunks generated by Duplicacy during backup will be identical in the source and new storage.

This has the effect that you can rsync or rclone the chunks folder for example from local (source) to Google Drive (new storage), and then only do backups on Google Drive, and the existing chunks will be identical (same name, same size) as if the backup was run locally.

The -bit-identical option does not copy the encryption option. It is possible to have an encrypted source and an unencrypted new storage, or vice versa. The -e option determines whether or not the new storage will be encrypted.

This means of course, that the added storage can have a different password from the source.

#27

Kind of. For the storage to be bit-identical the chunks need to be encrypted with the same keys, otherwise deduplication won’t work; and that would defeat the purpose.

When you create bit-identitcal storage, the encryption keys are copied from the source storage, instead of being generated anew. Then the contents of the config file is encrypted with the provided passphrase (via -e).

I was not aware that you could apparently provide different passphrase for the other storage, thank you for link. I’m not sure what’s the value in it – since the chunks are encrypted with the same key anyway.