Password verification is the process a system uses to decide whether a login attempt matches an account without needing to store the actual password. This matters because password databases are frequent targets for attackers, and storing readable passwords can expose every user at once. A secure system transforms the password into a protected value before saving it, then repeats the transformation during login to check for a match.
Good password verification reduces the damage from data leaks and makes large scale guessing attacks much harder.
Understanding How Passwords Are Verified
A hash function works like a one way mixing machine. It accepts input of any length and produces an output of fixed length. Even a tiny change in the input should produce a very different result.
This property makes reversing a stored result impractical in normal conditions. The system does not need to recover the original secret.
It only needs to see whether a new attempt creates the same protected result. In practice, a login server receives the typed password over an encrypted connection, performs its check, then should discard that typed value from working memory as soon as possible.
The main weakness is not usually the mathematics of hashing. It is human choice. People often choose short passwords, familiar words, names, or predictable changes such as adding a number at the end.
An attacker who obtains a database can try likely guesses first, using word lists and rules based on common habits. Password length matters because each extra independent character greatly increases the number of possible guesses. A long passphrase made from several unrelated words can be easier to remember than a short complicated string.
Reusing one password across sites is especially risky. A leak from one weak site can give attackers a useful guess for an email, bank, or school account.
Password storage must be designed for attacks that happen away from the login page. A rate limit can slow repeated attempts against a live account, but it cannot protect a copied database. This is why deliberate computational cost is important.
A password hashing method can require memory and time for every guess. That cost is small enough for one normal login, yet expensive when repeated millions of times. A modern method needs suitable settings, because computer hardware becomes faster over time.
Developers must increase the cost when appropriate and test that servers can still handle real users. Each account needs its own random salt, stored beside the protected value.
The salt is not secret. Its job is to stop attackers from benefiting when many people chose the same password.
Small implementation details can decide whether a sound design remains safe. The comparison step should use a constant time method, which avoids revealing where two values first differ through tiny timing changes. Password reset links must expire quickly, be hard to guess, and work only once.
Error messages should not reveal whether an account name exists, since that information helps attackers target users. Multi factor authentication limits harm when a password is stolen, but it does not make careless password handling acceptable. Students should separate the ideas of encryption and hashing.
Encryption is meant to be reversed with a key. Password hashing is meant for checking a guess without recovering the original password. When studying examples, pay attention to where secrets travel, what data is stored, how guesses are slowed, and what happens after a breach.
Key Facts
- A secure system stores hash = H(salt || password), not the plaintext password.
- A salt is a random value stored with each account so identical passwords produce different hashes.
- During login, the server computes H(stored salt || entered password) and compares it with the stored hash.
- Slow password hashing functions such as Argon2, bcrypt, or scrypt are preferred over fast general hashes like SHA-256 alone.
- Estimated brute force time = number of guesses needed / guesses per second.
- Multi-factor authentication adds another check, so access requires password match + second factor match.
Vocabulary
- Plaintext password
- A plaintext password is the original readable password typed by the user before any protective transformation.
- Hash function
- A hash function maps input data to a fixed length output in a way that is designed to be hard to reverse.
- Salt
- A salt is a unique random value added to a password before hashing to prevent identical passwords from having identical stored hashes.
- Password hashing function
- A password hashing function is a deliberately slow and configurable algorithm used to make password guessing expensive for attackers.
- Constant-time comparison
- A constant-time comparison checks two values without stopping early, reducing the chance that timing differences reveal useful information.
Common Mistakes to Avoid
- Storing passwords in plaintext is wrong because anyone who reads the database can immediately use every password.
- Using the same salt for every user is wrong because attackers can still compare accounts and reuse precomputed guessing work.
- Hashing with a fast general-purpose hash alone is wrong because attackers can try billions of guesses per second on specialized hardware.
- Returning overly specific login errors is wrong because messages like password incorrect but username exists can help attackers identify valid accounts.
Practice Questions
- 1 A password hashing function is configured to take 0.20 seconds per guess on one computer. How long would 10,000 guesses take on that computer, in seconds and in minutes?
- 2 An attacker can test 5,000,000 password guesses per second against unsalted fast hashes. How long would it take to test 2,000,000,000 guesses?
- 3 Explain why two users with the same password should still have different stored hash values in a well-designed password system.