Hashing is the process of converting input data into a digest using a function. Cryptographic hashes support integrity checks and password protection.

A cryptographic hash function produces a fixed-length output for its chosen configuration. Repeating the operation on the same input produces the same digest. A secure function makes it computationally difficult to recover an input from its digest or find different inputs with the same result.

That last property does not make a weak password safe. If an attacker guesses the input, they can calculate its hash and compare the result with a stolen value.

Password hashing needs more than a fast hash

General-purpose functions such as SHA-256 are designed to process data efficiently. That speed helps integrity checking but also helps attackers test large numbers of password guesses. Password storage needs a purpose-built password-hashing function with a configurable cost.

Modern designs such as Argon2id make guessing more expensive through computation and memory requirements. Work settings should be tuned for the service’s environment and reviewed as hardware changes. Established libraries handle the algorithm, salt and stored parameters more safely than a custom construction.

At sign-in, the service runs the supplied password through the same configured process and compares the result with the stored verifier. It does not decrypt a stored password.

What salting changes

A salt is a unique, randomly generated value included when hashing a password. It is stored with the resulting verifier and does not need to be secret. Two customers choosing the same password should receive different salts, so their stored verifiers do not expose the match.

Salts also stop attackers from efficiently reusing one precomputed lookup table across many accounts. They do not prevent an attacker from guessing a particular customer’s password. A separate secret value, often called a pepper, can add protection if kept apart from the password database, but it introduces key-management responsibilities.

Hashing compared with encryption

Encryption is designed to recover the original data using a suitable key. Cryptographic hashing does not provide that recovery operation. Tokenization instead substitutes another value for sensitive data, often with controlled retrieval through a separate service.

For a customer portal, these techniques solve different problems. The service may hash passwords for verification while encrypting documents it must later display to authorized customers. If attackers steal the password database, salted password hashing slows offline guessing but does not protect weak or reused passwords indefinitely.

Frequently asked questions

Can a hash be decrypted?

Cryptographic hashes have no decryption key. Attackers can still guess candidate inputs and compare their hashes, which is why password hashing needs a deliberate computational cost.

Should password salts be secret?

No. Salts should be unique and generated appropriately, and can be stored with the password verifier. A pepper is a separate secret with different storage requirements.

Is hashing enough to stop credential stuffing?

No. Credential stuffing uses passwords already obtained elsewhere. Password hashing protects stored verifiers; preventing reuse-based account abuse requires additional authentication and detection controls.

Related: Credential Management · Data Breach · Credential Stuffing · Passwordless Authentication · Brute-Force Attack · Authentication