Password Hashing and Salting: Store Credentials Securely
Never store plaintext passwords. Instead, use a slow, one-way hash combined with a unique salt for each user, making it computationally expensive to reverse. This is essential for any app with user logins.
Why it exists
The goal is to protect user credentials even if your database is compromised. If you store passwords in plaintext, a single data breach exposes every user's password, which they may have reused on other sites. Hashing and salting makes a stolen database of credentials almost useless to an attacker.
The mental model
Hashing is a one-way function, like turning a cow into a burger—you can't reverse the process. Salting is like adding a unique spice blend to each cow before grinding. Even if two users have the same password, their unique salts ensure their stored hashes will be completely different, preventing attackers from identifying common passwords or using pre-computed lookup tables (rainbow tables).
How it works
When a user signs up, you generate a unique, random string called a salt. You combine this salt with their password and feed the result into a strong, slow hashing algorithm like Argon2id, scrypt, or bcrypt. You store both the resulting hash and the salt in your database—never the original password. When the user logs in, you retrieve their salt, combine it with the password they just entered, and run it through the same hashing algorithm. If the new hash matches the stored one, access is granted. The slowness is a feature; these algorithms are designed to be computationally expensive to slow down attackers trying to brute-force guesses.
When to use it
Always use this process for storing any secret that a user provides for authentication, primarily passwords. It is a non-negotiable, foundational requirement for any system with user accounts, from web applications to mobile apps.
When not to use it
Do not use password hashing for data that needs to be retrieved in its original form. Hashing is a one-way process. If you need to store sensitive information that your application must decrypt and use later, such as an API key, you need two-way encryption, not one-way hashing.
One canonical example
The recommended modern standard is Argon2id. A secure configuration might use Argon2id with 19 MiB of memory, an iteration count of 2, and a parallelism of 1. If Argon2id isn't available, scrypt and bcrypt are strong alternatives. A common but critical mistake is using a fast hashing algorithm like SHA-256. While secure for other purposes like file checksums, it is dangerously fast for passwords, allowing an attacker with your stolen hashes to make billions of guesses per second.
Interview question
Which of the following best explains why fast hashing algorithms like SHA-256 are considered insecure for password storage, despite their cryptographic strength?
- a.Their rapid computation speed significantly aids attackers in performing brute-force and dictionary attacks against stolen hashes.Correct
- b.They do not support the use of unique salts, making them vulnerable to rainbow table attacks.
- c.They are susceptible to collision attacks, allowing attackers to find multiple passwords that produce the same hash.
- d.They are reversible, meaning an attacker can easily convert the hash back into the original plaintext password.
Why? this is the answer
The card explicitly states that fast algorithms like SHA-256 are "dangerously fast for passwords," enabling attackers to make "billions of guesses per second" in brute-force attempts. While SHA-256 is cryptographically strong for other purposes, its speed is a critical vulnerability for password hashing, unlike option C which is not the primary concern for password security with fast hashes.
Just read this? Test yourself on what you have been reading.
Read the original → cheatsheetseries.owasp.org
- #security
- #authentication
- #cryptography
- #passwords
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.
See open roles