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.

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

Markdown source

Copy this and paste it into Checksy to import the checklist.

Show markdown Hide markdown

---
template: true
about: 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.
---

# OWASP cryptographic storage checklist

## 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.

Try Checksy More checklists