Passwords, credentials and environment variables

How-to
, ,
#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.

#28

What happens if I forget the password of the storage?
Do I loose any the posibility of recover the backup?

#29

Without the storage password the data is unrecoverable. That’s the whole point of setting the password.

But you shall not try to remember it, use password manager.

#30

Is there an environment variable for specifying the password for a SAMBA backend?

#31

From the user guide: Managing Passwords · gilbertchen/duplicacy Wiki · GitHub

password type environment variable (default storage) environment variable (non-default storage in uppercase) key in preferences
Samba password DUPLICACY_SAMBA_PASSPHRASE DUPLICACY_<STORAGENAME>_SMB_PASSWORD smb_password

@gchen – there seems to be inconsistency with naming here – SMB vs SAMBA

#32

Oh nice! Didn’t occur to me to check the wiki @ github. Thanks!

#33

I’ve fixed it. Thanks!

1 Like
#34

What about Storj keys?

#35

What about it?

#36

Thank you for the reply. I appreciate your time.
To clarify my original question: I was referring specifically to the use of Storj as a storage backend with Duplicacy. I’m currently setting up Storj as one of my storage targets, and I would like to follow best practices for securely managing access credentials — ideally using environment variables.
I reviewed the table provided in the documentation, which lists the environment variable names for various password and token types (e.g., SFTP, Dropbox, B2, S3, etc.), but I did not see Storj mentioned there.
Could you please let me know:

  • What are the correct environment variable names used by Duplicacy to pass Storj-related access information (such as the access grant or API key)?
  • Are there specific keys in the preferences file that correspond to Storj credentials?
  • Does Duplicacy currently support retrieving Storj credentials from secret vaults (e.g., Keychain on macOS, gnome-keyring on Linux, or the Windows DPAPI)?

Thank you again for your help. I just want to make sure I’m configuring everything in a secure and recommended way.

#37

It’s definitely there: search “Storj” on this page Managing Passwords · gilbertchen/duplicacy Wiki · GitHub

Ideally you would want to keep them in the keychain. Environment variables can be seen by a superuser.