The Runtime Theory
mediumServerInternals#password-hashing#least-privilege

Why Is a Password Hashed Instead of Encrypted?

A security prompt about password verifiers, salts, offline guessing, authentication, session creation, and authorization.

TRT practice prompt — not a verified question from a named employer.

The Runtime Theory Team1 min read

A strong answer

An application normally needs to verify a submitted password, not recover the original password. It stores a password verifier generated with a password-hashing function, a unique salt, and parameters that make guessing expensive. If the database leaks, an attacker must test guesses against those verifiers rather than decrypt a reversible copy of every password.

Encryption is appropriate when the system must recover data and can protect the decryption key. Passwords should not be recoverable in this way. A fast general-purpose hash allows an attacker to test many guesses quickly; password-hashing schemes are deliberately slower or memory-hard, and their parameters need to be reviewed as hardware changes.

After verification, the server creates an authenticated session with a new identifier and protected cookie settings. Authentication establishes identity; authorization still checks permission for each resource and action.

Follow-up direction

Discuss rate limiting and multi-factor authentication as additional controls, then reference current password-storage guidance rather than inventing parameters from memory.

This answer walks

Practice follow-ups

  1. 01Why is a fast general-purpose hash unsuitable for password storage?
  2. 02What is the role of a unique salt?
  3. 03After authentication, where should authorization be enforced?

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save