Password Hashing Flow: Mermaid Flowchart Diagram

About Source

Password hashing is the process of converting a plaintext password into a fixed-length derived value that can be stored safely, such that the original password cannot be recovered from the stored value even if the database is compromised.

Storing plaintext passwords is never acceptable. Even storing passwords with a simple hash like MD5 or SHA-256 is dangerous because these functions are designed to be fast, which means an attacker with the hash can test billions of guesses per second using a GPU. Password hashing algorithms solve this by being deliberately slow and memory-intensive.

Modern password hashing uses adaptive algorithms specifically designed for this purpose: bcrypt, scrypt, Argon2id, and PBKDF2. Argon2id is the current recommendation from OWASP and the Password Hashing Competition winner. These algorithms accept a configurable work factor (cost parameter) that you increase over time as hardware gets faster, keeping brute-force attacks expensive.

A critical component is the salt: a cryptographically random value (typically 16+ bytes) that is generated uniquely for each password and prepended to the password before hashing. The salt is stored alongside the hash in the database. Salts prevent precomputed dictionary attacks (rainbow tables) by ensuring that identical passwords hash to different values.

During registration, the server generates a random salt, combines it with the password, runs the result through the chosen algorithm at the configured work factor, and stores the salt and hash together (the algorithm encodes both in a single string in modern implementations like $argon2id$v=19$m=65536...). The plaintext password is never stored.

During login, the server retrieves the stored hash, extracts the salt and parameters, re-hashes the submitted password with the same parameters, and compares the result to the stored hash using a constant-time comparison. See Secure Session Storage for what happens after a successful login.

Frequently asked questions

Password hashing is the one-way transformation of a plaintext password into a fixed-length value using a deliberately slow algorithm. The hash is stored in the database instead of the password. At login, the submitted password is re-hashed and compared — the original plaintext is never stored or recoverable.

SHA-256 and MD5 are designed to be fast, which means attackers can test billions of guesses per second against a stolen hash database. bcrypt, scrypt, and Argon2id are intentionally slow and memory-hard, making brute-force attacks orders of magnitude more expensive. Their work factors can be increased over time as hardware improves.

A salt is a unique random value generated for each password and stored alongside the hash. It ensures that two users with the same password produce different hashes, which defeats precomputed rainbow table attacks. Modern algorithms like Argon2id embed the salt in the output string automatically.

mermaid

flowchart TD
    subgraph Registration
        A[User submits password] --> B[Generate cryptographically\nrandom salt 16+ bytes]
        B --> C[Combine password + salt]
        C --> D[Run Argon2id / bcrypt\nwith configured work factor]
        D --> E[Produce hash string\nincludes algorithm + salt + hash]
        E --> F[Store hash string in database\nNEVER store plaintext]
    end

    subgraph Login
        G[User submits password attempt] --> H[Retrieve stored hash\nfrom database]
        H --> I[Extract salt and parameters\nfrom stored hash string]
        I --> J[Re-hash submitted password\nwith same salt and parameters]
        J --> K[Constant-time comparison\ncomputed hash vs stored hash]
        K --> L{Hashes match?}
        L -- Yes --> M[Authentication successful\nCreate session or issue token]
        L -- No --> N[Authentication failed\nReturn 401 Unauthorized]
    end