News
Zero-Trust Credential Safety: Securing Passphrases with Native Secret Providers
Storing backup passphrases and API keys in plain-text configuration files creates immediate security vulnerabilities and compliance risks. Discover how Duplicati leverages native OS keyrings, isolated secret providers, and least-privilege access models to deliver true Zero-Trust credential safety
In modern infrastructure, the perimeter has vanished. Trusting the local environment simply because it sits behind a corporate firewall is no longer a viable security posture. As backup systems touch your most critical and sensitive data, they also require access to highly privileged credentials: cloud API keys, storage tokens, and encryption passphrases. Storing these credentials in plain-text configuration files creates immediate local security vulnerabilities.
For a robust Zero-Trust architecture, secrets must be dynamically injected and securely managed at the operating system level. In this article, we explore how Duplicati addresses this challenge through its native secret provider integrations, ensuring your backups remain heavily armored against local compromise.
The Vulnerability of Plain-Text Configurations
Historically, many applications have relied on simple configuration files or environment variables populated via unencrypted scripts. If an attacker, or even internal malware, gains unauthorized read access to a server or workstation, plain-text files are trivially scraped.
Frameworks like SOC 2, ISO 27001, and HIPAA strictly forbid the storage of plain-text passwords or API keys on disk. Compromising a backup agent's plain-text configuration could grant an attacker direct access to cloud storage buckets and the ability to exfiltrate or delete critical data archives.
Integrating Native OS Keyrings
To eliminate plain-text risks, Duplicati's architecture utilizes a modular secret provider loader. This allows the application to offload the storage and retrieval of passphrases and tokens to the operating system's heavily encrypted, native key management systems.
If a working keyring is found, Duplicati will automatically create a secure strong key, store it in the keyring, and apply database encryption. Once the database encryption is applied, any secrets entered into the Duplicati application are written to the on-disk database with AES-256 encryption. If no working keyring was found, a warning will display inside Duplicati informing you that the database could not be encrypted.
Windows Credential Manager
On Windows environments, Duplicati can seamlessly interface with the Windows Credential Manager. Secrets are encrypted using the Windows Data Protection API (DPAPI), meaning they are tied to the specific user account or machine executing the backup schedule. An attacker copying the database cannot decrypt the credentials on another machine.
Linux: libsecret & KDE Wallet
For Linux endpoints, Duplicati supports standard freedesktop.org secret protocols. By integrating with libsecret (often backed by GNOME Keyring) or KDE Wallet, passphrases remain locked inside the user's encrypted keyring. The keyring is automatically unlocked upon user login, safely passing the required tokens to Duplicati in memory without ever writing them to disk.
macOS: KeyChain
With MacOS systems, Duplicati integrates fully with the macOS KeyChain, leveraging the full support of the Secure Enclave. The KeyChain is unlocked when the user logs in and secrets stay secured with no option for creating a copy.
Securing Headless & Tightly Isolated Servers
While native keyrings are excellent for workstations, they present unique challenges on headless Linux servers or tightly isolated containerized environments where no active user session exists to unlock a wallet.
Safely Disabling Default Secret Providers
All the default secret providers rely on operating system support to secure the secrets within the current user context. But on headless Linux or in a containerized deployment there is no desktop and no login that can unlock the secrets.
Instead of falling back to plain-text configs, headless servers should utilize:
Environment Variables (In-Memory Injection): Inject credentials directly into the container/process environment via a CI/CD pipeline or orchestration tool (e.g., Kubernetes Secrets) so they exist only in memory.
Use Cloud Provider Secret Stores: Besides the desktop secret providers, Duplicati also supports HashiCorp Vault, Amazon Secret Manager, Google Cloud Secret Manager, and Azure KeyVault. If you are running Duplicati and already using one of the supported providers, you can securely connect to the secret provider.
Using a cloud secret store also allows you to rotate secrets simply by updating the store, the same way you would rotate any other secret.
Implementation Checklist for Zero-Trust Backups
[ ] Audit Existing Jobs: Review all current backup configurations and remove statically defined API keys or cloud passwords from the GUI/CLI arguments where native providers or IAM roles can be used.
[ ] Enable OS Keyrings: Validate that Windows Credential Manager, macOS KeyChain, or
libsecretis active and correctly loading Duplicati's local encryption passphrases.[ ] Rotate & Restrict: Rotate all cloud storage tokens. Ensure the new keys are scoped as narrowly as possible.
[ ] Monitor Key Access: Utilize OS-level auditing to monitor which processes are reading the keyring, ensuring only the verified Duplicati executable is retrieving the secrets.
Want to learn more about the secret providers in Duplicati? Head over to the Secret Provider documentation!



