A salt makes password hashes unique, an IV starts a block cipher mode such as CBC, and a nonce is a number that must never repeat under one key. All three are usually public. What differs is the job, the rule for generating them, and the damage when you get it wrong.
The three terms side by side
| Value | Used with | Must be secret? | Rule |
|---|---|---|---|
| Salt | Password hashing | No | Unique per password, random |
| IV | Block cipher modes such as CBC | No | Unpredictable in CBC, never fixed |
| Nonce | Modes such as GCM, and protocols | No | Unique per key, never reused |
The words overlap in practice. Libraries often use IV and nonce for the same parameter, so read the documentation for the exact rule of the mode you use.
Salt
OWASP says a unique salt must be added to each password, which defeats precomputed tables. Most password hashing libraries generate the salt for you and store it inside the output string. You should not invent your own.
IV
CWE-329 describes the weakness of using a predictable IV with CBC: it makes encryption vulnerable to dictionary attacks when data is encrypted under the same key. NIST's two approved methods for CBC are to generate the IV randomly, or to encrypt a unique nonce with the same key and cipher. A constant IV, such as all zeros copied from an example, is the common mistake.
Nonce
For authenticated modes like GCM, the nonce rule is about uniqueness under one key. OWASP lists IV uniqueness across all instances sharing the key as a limit to enforce during key rotation. It also gives an AES-GCM example of limiting each key to at most 2 to the power of 32 encryption operations across all devices sharing that key. If you run many workers, a simple counter in each process is not enough, so prefer a library that handles it or a key per instance.
What to store with the ciphertext
Store the IV or nonce next to the ciphertext, since you need it to decrypt. Store the salt inside the password hash string. None of them need protecting, but all of them must be the exact value used at encryption time.
A short checklist
- Never hard code an IV or nonce.
- Let the library generate it from a secure random source.
- Do not derive it from the message or a timestamp unless the mode documents that.
- Record it with the ciphertext.
- Cap the number of messages per key.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Can I reuse one IV for a whole table of encrypted fields?
No. A reused IV in CBC leaks which values match, and a reused nonce in GCM is far worse. Generate a fresh one per value.
Is a salt the same as a pepper?
No. A salt is public and unique per password. OWASP describes a pepper as a shared secret stored separately from the database that adds defense in depth.
Sources
- OWASP Password Storage Cheat Sheet
- CWE-329
- OWASP Cryptographic Storage Cheat Sheet
- OWASP Key Management Cheat Sheet
Last reviewed: 19 October 2026.
