Key and Secret Management: General Good Practices

The strongest algorithm in the world is useless if the key is written on a sticky note, committed to a public repository or reused everywhere. In real incidents, attackers rarely break cryptography; they find the keys and passwords that were left lying around. This final lesson of the chapter is about the human and organisational side of cryptography: how to generate, store, share, rotate and retire keys and secrets, in a way that keeps them secret.

Over the last three lessons you met hashes, symmetric and asymmetric keys and certificates. Every one of them depends on something staying private. This lesson shows how.

What counts as a secret?

A secret is any value whose disclosure would let someone do what they should not. The list is longer than most beginners think:

• Passwords and passphrases.
• Private keys (SSH, TLS, signing keys).
• API keys and access tokens for services.
• Database connection strings with credentials.
• Session tokens and cookies (temporary, but powerful while valid).
• Encryption keys for disks, backups and databases.
• Recovery codes of multi-factor authentication.

The first step of good management is to know where your secrets are. An inventory, even a simple one, is the foundation. You cannot protect what you have forgotten.

Where secrets leak

Most leaks are mundane, not sophisticated:

• Source code repositories: a developer commits a password, an API key or a private key. If the repository is public, automated bots scan new commits for patterns of secrets and exploit them very quickly, sometimes within minutes. Deleting the file in a later commit does not erase the history.
• Configuration files and scripts copied around, with credentials inside.
• Chat messages, emails, tickets and wikis where someone pasted a password "just this once".
• Logs that record requests or environment values, including tokens.
• Backups and disk images stored without encryption or with weak access control.
• Shared accounts whose password everybody knows, including people who left the company.
• Client-side code: anything shipped to a browser or a mobile app can be inspected, so secrets must never be embedded there.

Principles of good practice

1. Generate them properly

Keys must come from a cryptographically secure random generator, not from something a person invents. Use the tools provided by your platform (ssh-keygen, openssl, the key generation feature of a trusted library). Use sizes and algorithms currently recommended by official bodies such as ANSSI and NIST, and avoid obsolete ones.

2. Never hard-code secrets

Do not put a secret in source code. Load it at run time from a place designed for it, such as environment variables injected at deployment, protected configuration files with strict permissions outside the code repository, or, better, a dedicated secrets manager (sometimes called a vault) that stores secrets encrypted, controls who can read them, and keeps an audit trail. Environment variables are better than code but not perfect, since they can show up in process listings or crash reports, so treat them with care.

For repositories, add rules so that secret files are never committed (the .gitignore file lists files to ignore), and consider automatic scanners that detect secrets before a commit is accepted.

3. Least privilege and separation

Give each application or person its own credentials with the minimum rights needed, rather than a single master key for everything. A read-only database account for a reporting tool; a deploy key limited to one repository. If one secret leaks, the damage stays contained. Use separate secrets for development, testing and production.

4. Protect the storage

• Set strict file permissions: a private key file should be readable only by its owner (chmod 600), as in lesson 2 of chapter 4.
• Protect private keys with a passphrase when stored on disk.
• For the most valuable keys, such as the signing key of a certificate authority or a company's main encryption key, use dedicated hardware: hardware security modules (HSM) or security tokens that perform cryptographic operations without ever exposing the key.
• Encrypt backups, and protect the backup of the keys separately from the data they protect. Storing the key next to the encrypted data defeats the purpose.
• For personal use, rely on a password manager, as seen in the first course, and keep recovery codes offline.

5. Share carefully

Never send a secret in the clear through email or chat. Prefer a secrets manager or an encrypted channel, give a person access rather than copying the value, and share a temporary password through a separate channel from the account name. Avoid shared accounts; individual accounts make logs meaningful.

6. Rotate and expire

Secrets should not live forever. Rotation means replacing a secret regularly and, importantly, whenever there is a suspicion of compromise, when a person leaves, or when a system changes hands. Short-lived credentials, such as tokens that expire in minutes or hours, reduce the value of a stolen one. Certificates have an expiry date for the same reason, and many organisations automate their renewal to avoid outages from forgotten expiry dates.

7. Plan for compromise

Assume that sooner or later a secret will leak, and prepare for it. You need to know how to revoke it quickly (invalidate the key, cancel the certificate, disable the token), how to replace it without long downtime, and how to check logs for abuse during the period of exposure. If a secret ever appears in a public repository, treat it as compromised immediately: revoke and replace it, rather than only deleting the file.

8. Audit and monitor

Know who accessed what secret and when. Alert on unusual use: a key used from an unexpected location, or a sudden surge of requests. Review access rights periodically and remove those no longer needed.

A note on your lab

In your lab you will create many throwaway passwords, keys and certificates. It is fine to use simple secrets for deliberately weak lab targets, but build the habits now: use separate credentials from your real accounts, keep private keys with restricted permissions, never reuse a lab password in real life, and do not push lab files that contain keys to any public repository. Habits learned in a lab are the ones that you will carry to a job.

Your turn: audit your own secrets

Do a personal secrets audit in your lab and on your own computer. First, list in your notebook every secret you created during this course (passwords of VMs, SSH keys, the lab certificate key) and where each one is stored. Second, check the permissions of your SSH private key and lab certificate key with ls -l and fix them to 600 if needed. Third, search your lab notes and scripts for passwords written in clear text, for example with grep -rni "password" ~/lab. Fourth, write for each secret: who may use it, when you will rotate or delete it, and what you would do if it leaked.

See a solution

A sample entry: "Lab SSH key: stored in ~/.ssh/id_ed25519 on the Kali VM, protected by a passphrase, permissions 600. Used only to log in to the lab server. Deleted when the lab is rebuilt. If it leaked, I remove its public key from authorized_keys on the server and generate a new pair." For the notes search, you will probably find at least the test passwords you typed in earlier exercises: move them into a password manager or delete them, and make it a rule that notes contain commands and observations but not secrets. If you used a sample password in a script, replace it with a prompt (read -s) or with a variable loaded from a protected file.