NEW
A unique random value added to inputs before hashing to prevent precomputation and hash reuse attacks.
DESCRIPTION
A salt is random data combined with a password or input before hashing, ensuring the resulting hash is unique even for identical inputs. Unique per-record salts thwart rainbow tables and make parallel cracking less efficient. Salts are stored alongside the hash and are not secrets. They are essential in password hashing schemes with KDFs such as PBKDF2, scrypt, or Argon2. Proper salt length and randomness are critical for effectiveness.
ALTERNATIVE DEFINITIONS
OWASP Cheat Sheet Series
A salt is a unique, randomly generated value that is added to the password before hashing.
Stresses uniqueness and randomness as key properties.
NIST SP 800-63B
Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks.
Mandates salted, slow hashing indirectly by specifying resistance to offline attacks.
RELATED TERMS
Password-Based Key Derivation Function 2 scrypt bcrypt Argon2 Password Hashing Key Derivation Function Rainbow Table Entropy Credential Stuffing
COMPETING TERMS
KNOWLEDGE AREAS
Data Security Data Privacy & Compliance
TARGET AUDIENCE
Security Architect Cybersecurity Engineer Software Developer DevOps Engineer
EXTERNAL SOURCES
- Wikipedia - Salt (cryptography)
- OWASP - Best practices for salting and hashing passwords.
- IETF RFC 8018 (PKCS #5 v2.1) - Standard defining PBKDF2 and salt usage.
TOP QUESTIONS
Why is a salt necessary in password hashing?
Salts ensure identical passwords produce different hashes, preventing rainbow table and hash reuse attacks.
Category: Relevancy
Should salts be secret?
No. Salts are stored with the hash and need not be secret; their uniqueness and randomness provide the security benefit.
Category: Misunderstanding
How long should a salt be?
Use at least 16 bytes of cryptographically secure randomness; longer salts further reduce collision probabilities.
Category: BestPractices
How do salts interact with KDFs like PBKDF2 or scrypt?
The KDF takes the password and salt as inputs, producing a derived key resistant to offline attacks.
Category: Concepts
Is a global salt acceptable?
No. Each credential must have a unique per-record salt; global salts enable large-scale attacks.
Category: Mistakes
Can I use user IDs as salts?
No. User IDs are predictable and may repeat; use cryptographically random salts.
Category: Mistakes
Does salting slow attackers?
Yes, by forcing per-record work and thwarting precomputation; combined with slow KDFs, it significantly increases attack cost.
Category: Benefits
What else should accompany salts?
Use memory-hard or iterated KDFs (e.g., Argon2, scrypt, PBKDF2) and enforce strong password policies.
Category: Requirements
Where to learn more about salts?
Consult OWASP Password Storage guidance and relevant IETF standards like RFC 8018.
Category: GettingStarted