Password storage is easy to describe badly. “Hash the password” is technically better than storing plaintext, but it leaves out the decisions that determine whether a stolen password database can be cracked quickly or only after substantial effort. A secure verifier has to choose an appropriate password-hashing scheme, generate a unique salt, set a cost that is expensive enough for attackers but sustainable for legitimate logins, protect any additional server-side secret, and retain enough metadata to migrate the scheme later.
The right mental model for SY0-701 is a workflow. Follow a password from enrollment to verification, then imagine an attacker stealing the stored verifier data and running guesses offline. The value of hashing, salting, cost factors, and optional keyed protection becomes much clearer when each control is tied to that attack path.
A password verifier should not need to recover the original password
Encryption is reversible when the correct decryption key is available. Password verification normally does not need that property. The system only needs to determine whether the password presented during login corresponds to the value established earlier.
That is why storing passwords with a one-way password-hashing scheme is preferable to reversible encryption. At enrollment, the verifier derives a stored value from the password, a salt, and a configured cost. At login, it repeats the derivation using the submitted password and the stored parameters, then compares the result.
If the database is stolen, there is no decryption key that simply reveals every password. The attacker instead has to guess candidate passwords, process each guess through the same hashing scheme, and check for matches. The security objective is to make that offline guessing process expensive enough that weak choices are exposed less quickly and strong choices become impractical to recover.
A salt makes identical passwords produce different stored values
A salt is a per-password value stored alongside the password verifier. It does not need to be secret. Its job is to ensure that two users who choose the same password do not normally end up with the same stored hash and to defeat large precomputed tables that assume a password always maps to one reusable hash value.
Without salts, an attacker can hash a candidate once and compare it against every account in a database. Repeated values also reveal which accounts share a password. With unique salts, the attacker has to perform the expensive derivation separately for each target account and salt combination.
Salting does not turn a weak password into a strong one. If an attacker steals the database and knows the salt—as expected—the attacker can still guess common passwords. The difference is that the guessing work cannot be amortized as efficiently across users or through generic precomputed lookup tables.
This is why user behavior and server-side storage have to be considered together. Common password habits that weaken account security remain relevant even when the backend storage is engineered correctly.
The work factor is where economics enters the design
Password-hashing schemes are intentionally expensive compared with fast general-purpose hashes. They are designed so legitimate verification is still acceptable while large-scale offline guessing consumes substantial CPU, memory, or both.
The cost setting is not a value to choose once and forget. Hardware improves over time, and attackers can invest in parallel computing. NIST’s current guidance says the cost factor should be as high as practical without negatively affecting verifier performance and should increase over time as computing capability grows.
That produces a real engineering trade-off. Set the cost too low and a stolen database becomes cheap to attack. Set it too high and authentication latency, server load, autoscaling cost, or denial-of-service exposure can become unacceptable. The correct setting depends on the algorithm, infrastructure, login volume, and acceptable latency.
Benchmarking should therefore be part of deployment and periodic review. The team should know the expected verification cost on production-class hardware and how the service behaves under bursts of legitimate and malicious login attempts.
Memory hardness changes the attacker’s scaling problem. Fast cryptographic hash functions are valuable for many security tasks, but speed is not desirable for password verification. Modern password-hashing schemes can deliberately consume memory in addition to computation. This makes certain highly parallel guessing platforms more expensive to scale because the attacker must provide meaningful memory resources for each concurrent guess.
The important concept is not to memorize one fashionable algorithm name. It is to understand that a password hash should be selected for password hashing, configured with an appropriate cost, and supported by an upgrade plan. A general-purpose fast hash used with a salt may still leave attackers able to test enormous numbers of guesses per second.
Organizations also need algorithm agility. The stored record should include which hashing method and parameters were used so the verifier can recognize older records and migrate them when policy changes.
Rehash on successful login is a practical migration technique
Suppose an organization raises its work factor or moves to a newer password-hashing scheme. It may not know users’ plaintext passwords, so it cannot simply recompute every record offline. One practical approach is to migrate accounts when users authenticate successfully.
The server verifies the submitted password using the old stored parameters. If the login succeeds and the record is below the current policy, the server immediately derives a new verifier using a fresh salt and the current scheme, then replaces the old record.
This gradually upgrades active accounts without requiring the organization to retain plaintext passwords. Dormant accounts can be handled through expiration, forced reset, or another controlled process. The technique also illustrates why version and cost metadata belong with the stored verifier.
A separate server-side secret can add another barrier
NIST’s current digital identity guidance recommends that verifiers consider an additional keyed hashing or encryption operation using a secret known only to the verifier, stored separately from the password database and preferably protected by hardware such as an HSM or trusted execution environment.
This design is sometimes informally described as adding a “pepper.” Unlike a salt, the server-side key is secret. If an attacker steals only the password database but not the protected key, the attacker lacks an input required to validate guesses in the same way the server does.
The protection is only useful if the secret is actually separated. Storing the key in the same database dump, source repository, or easily accessible configuration file collapses the intended boundary. It also introduces operational requirements for key rotation, backup, disaster recovery, and availability.
This is an example of a recurring security principle: a second control is valuable when it fails independently of the first. Copying two secrets into the same compromise domain does not provide meaningful separation.
Online guessing and offline cracking are different problems
Rate limiting, lockout policy, bot detection, and risk-based authentication can make online password guessing difficult because every attempt passes through the live service. Once an attacker steals the password verifier database, those online controls no longer apply. The attacker can test guesses on their own hardware.
Password hashing is therefore primarily a control for the offline threat. Rate limiting still matters for live authentication, but it cannot compensate for weak storage after a breach. Conversely, an expensive password hash does not prevent credential stuffing when users reuse a password that has already been exposed elsewhere.
A complete account-security design combines strong storage, sensible online protections, breach-password screening, and stronger authentication where appropriate. Authentication methods beyond traditional passwords are especially important for accounts whose compromise has high impact.
Reset and recovery can bypass the carefully protected password
An application may store passwords perfectly and still expose accounts through a weak reset flow. If the password can be replaced after answering predictable questions, taking over an email account, or persuading a support agent, the attacker never needs to crack the stored hash.
Password reset should therefore be threat-modeled as an authentication process of its own. The system needs to decide how identity is re-established, how temporary reset tokens are protected, how long they remain valid, what sessions are revoked afterward, and how the user is notified.
The same applies to administrator-initiated resets. Help-desk staff should not become an invisible alternate authenticator with broad authority and weak verification. High-risk accounts may require stronger recovery steps or escalation.
This boundary is explored more broadly in authentication attack patterns, where the weakest lifecycle step often determines the practical security of the whole account.
A breach drill reveals whether the storage design is actually resilient
A useful review begins with the assumption that the authentication database has been copied by an attacker. Identify exactly what the attacker obtains: hash output, salt, algorithm identifier, cost parameters, account metadata, and perhaps a server-side keyed value if separation failed.
Then ask what remains outside the breach boundary. Is the additional server key held in an HSM? Are strong work factors in use? Are users with privileged accounts protected by phishing-resistant MFA? Can the organization force resets and revoke sessions? Can it identify which stored records still use an obsolete scheme?
The exercise should also test availability. Password hashing consumes resources by design, so defenders need limits that prevent attackers from turning expensive verification into an easy denial-of-service tool. Caching the wrong things, disabling costs under load, or creating insecure “fast paths” can undermine the storage model.
The engineering goal is to make stolen verifiers expensive and short-lived
Good password storage cannot make weak passwords unguessable, and it cannot stop every account takeover technique. What it can do is transform a database theft from instant disclosure into a costly guessing problem, reduce the attacker’s ability to reuse precomputed work, and give the organization room to respond.
The essential design is straightforward: use a password-specific hashing scheme, generate a unique salt, choose a cost high enough for current hardware, record the parameters for future migration, consider a separately protected server-side key, and keep reset, session, and MFA controls inside the same threat model.
Within CompTIA Security+, hashing and salting are most useful when understood as engineering choices inside an authentication system. The defender is not trying to hide the algorithm or the salt. The defender is deliberately making every offline password guess expensive while keeping the legitimate verification path manageable, observable, and upgradeable.
