Secrets management with AES encryption

Every automation platform eventually becomes a vault. SSH keys, API tokens, passwords, … they accumulate quietly until, one day, you realize your backend database holds more sensitive material than some password managers.

Until now, CTFreak stored those values in plain text. The database itself might be protected by access controls and network segmentation, but the secrets inside were readable by anyone with a database client and the right credentials. A leaked backup, a compromised read replica, and suddenly every credential in the system is exposed.

Encryption adds a second barrier: even with the raw data in hand, an attacker still needs the key. It is also the kind of control that compliance auditors look for. PCI-DSS, SOC 2, ISO 27001 all expect sensitive data to be encrypted. Having it built into your automation platform means one less gap to explain during an audit.

Starting with version 1.38.0, Business and Sovereign Edition users can encrypt every sensitive field using AES-256-GCM, and switching it on takes a single command.

What’s covered

The scope is deliberately broad: credential passwords, SSH private keys, database connection passwords, OIDC client secrets, integration API tokens, webhook secrets, notifier webhook URLs, SMTP passwords, and even the license key. In short, everything that would be dangerous in the wrong hands.

Task definitions, execution logs, and user profiles stay in clear text. They aren’t secrets, and encrypting them would just burn CPU cycles for no security benefit. User passwords and Personal Access Tokens are also excluded, since they are already stored as irreversible hashes.

One command to rule them all

Stop your CTFreak instance first, then run:

ctfreak encrypt AES

CTFreak generates a fresh 256-bit AES key, encrypts every secret in a single atomic transaction, and saves the key to the configuration file. If anything goes wrong, the transaction rolls back. Nothing changes until everything succeeds.

The key lives in the config file, the encrypted data lives in the database. This separation is where most of the security value comes from. With a PostgreSQL backend, it happens naturally: the database is on one server (or a managed service), the config file on another. An attacker who compromises one side still has nothing usable without the other.

The same command doubles as key rotation. Running it again when AES is already active generates a new key and re-encrypts everything from scratch, no extra tooling required. Schedule it quarterly, run it after a team change, or whenever your security policy calls for it.

Need to revert for debugging or migration? ctfreak encrypt PLAIN decrypts everything back.

What changes for your users

Nothing. The encryption layer is completely transparent. The web interface looks the same, the API behaves the same, and CTFreak handles encryption and decryption on the fly. Performance impact is negligible thanks to AES-NI hardware acceleration on modern CPUs.

Getting started

CTFreak 1.38.0 is available now. For the complete reference, head to the Secrets documentation.

Happy encrypting!