How Symmetric Encryption (Fernet) Keeps Local Credentials Safe on Disk

Desktop applications that communicate via SSH or APIs frequently require remembering passwords or keys between sessions. Requiring the user to input it each time is impractical, yet storing it in cleartext within a configuration file poses significant risks. If the file finds its way into backups, shared folders, or gets forwarded for debugging, the credentials become exposed.

This article explores how symmetric encryption tackles this precise issue using Python's cryptography library and its Fernet implementation as an illustrative example. Symmetric encryption employs the same key for both encryption and decryption processes, contrasting with the asymmetric encryption used in SSH keys (RSA/ED25519/ECDSA), which involves a pair of public and private keys.

Asymmetric encryption serves to authenticate or communicate between separate parties without sharing any secret, a concept that differs fundamentally from symmetric encryption, which is designed for a single program to encrypt data for its own use.

Symmetric encryption is the optimal choice for local credential storage since there is no second party to establish a key exchange with. A single securely stored key suffices. The Fernet method, part of Python's cryptography library, bundles numerous secure techniques into a simple, secure-to-use process. It employs AES for encrypting the data payload, HMAC for signing the ciphertext to detect tampering, an embedded timestamp for potential expiration checks, and URL-safe Base64 encoding to convert the entire package into a printable string suitable for JSON or text files.

A critical aspect of Fernet is its ability to authenticate data, rather than simply ensuring confidentiality. Without an integrity check, encrypted data could still be tampered with, albeit without the key. Fernet's built-in HMAC verification prevents such alterations by failing decryption outright if the token has been modified since creation.

The management of the encryption key is the most challenging aspect of implementing symmetric encryption. The key itself holds the power to decrypt the data, and losing it renders the encrypted information irretrievable. This presents a separate failure mode compared to a forgotten password, which can be reset. Therefore, safeguarding the key is crucial and warrants meticulous care.

The application generates a key upon the first execution and stores it in a hidden directory with restricted permissions. To mitigate the risk of accidental deletion or corrupted profiles, a duplicate of the key is maintained in another location, ensuring that the app checks both locations upon startup. If one copy is missing, the available copy is restored.

The encryption key's location is a critical but often overlooked aspect. Storing it in a single location can lead to data loss in case of accidental deletion or disk errors. Distributing the key across multiple locations and reconciling them each time the application starts is essential to prevent unrecoverable data loss. Identifying an encrypted value by prefixing it with "ENC:" allows for idempotent encryption – calling the function on already-encrypted values won't duplicate the encryption process.

This prefix also enables the app to coexist between plaintext and encrypted data without ambiguity, facilitating a seamless transition to encryption.

Adding encryption support to an existing application can be done gradually, as new fields get encrypted immediately while older entries are encrypted the next time they are saved. Encrypting fields selectively rather than by default offers a balance between security and usability. By explicitly defining which fields to encrypt, the app can safeguard sensitive information while keeping the rest of the configuration file readable and diffable, avoiding unnecessary obfuscation of non-sensitive data.