Checklist

OWASP cryptographic storage checklist

A checklist based on the OWASP Cryptographic Storage Cheat Sheet. Use this when designing or reviewing how secrets, passwords, and sensitive data are stored at rest.

https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html

33 items
7 sections
Reusable template

Your progress

0 of 33 items complete

complete

Saved in your browser. Sign in to Checksy to share progress with your team.

Algorithm selection

Use vetted, current algorithms (AES-GCM, ChaCha20-Poly1305, RSA-OAEP, ECDSA P-256+)
Avoid deprecated algorithms (DES, 3DES, RC4, MD5, SHA-1, ECB mode)
Prefer authenticated encryption (AEAD) over plain encryption
Use the platform's standard crypto library; never roll your own
Document the algorithm, mode, and key size for every use

Key generation and storage

Generate keys with a cryptographically secure RNG
Store keys in a KMS, HSM, or vetted secrets manager
Never check keys into source control or container images
Restrict who and what can read each key
Log key access and alert on unusual patterns

Key lifecycle

Keys have a defined rotation schedule
A key compromise procedure is documented and tested
Old keys remain available only long enough to decrypt prior data
Each key has a single, documented purpose (no key reuse across services)
Keys are versioned and the version travels with the ciphertext

Password hashing

Hash with Argon2id, bcrypt, or scrypt
Use a unique salt per password
Tune work factors for current hardware; review yearly
Apply a server-side pepper stored separately from the database
Re-hash on next successful login when parameters change

Encryption at rest

Classify data and only encrypt what truly requires it
Use envelope encryption with a KMS-managed master key
Use unique IVs/nonces per encryption operation
Store ciphertext, IV, and key version together
Encrypt backups, snapshots, and exports the same way

Random number generation

Use a CSPRNG (`SecureRandom`, `secrets`, `crypto.randomBytes`, etc.)
Never use `Math.random`, `rand()`, or other non-cryptographic RNGs for security
Use enough entropy (≥ 128 bits) for tokens, salts, and IDs

Secret management

API keys, DB passwords, and tokens live in a secrets manager
Secrets are injected at runtime, not baked into images
Each environment (dev, staging, prod) has its own secrets
Compromised secrets can be rotated without a code deploy
Secret access is audited

Run this checklist for real

Save your progress, share with your team, and turn this into a reusable template. This helps you track how you improve over time.

Use in Checksy More checklists