Secure password hashing and storage
Scope
This document describes how user passwords are securely hashed and stored, including an example flow and visual illustration of the process.
I am new. Where should I start?
Purpose
This guide explains:
What happens to your password after you enter it
How hashing and storage protect your credentials
Why passwords cannot be recovered even by system administrators
Prerequisites
This applies to:
Any user creating or updating a password
Any sign-in attempt using email and password
I already understand. How do I proceed step by step?
1. Password handling flow (high-level)
Step-by-step overview
User enters a password on the sign-up or sign-in page
Password is transmitted securely using HTTPS (TLS encryption)
The system hashes the password using a secure algorithm
Only the hashed value is stored in the database
At no point is the original password stored or logged.
2. Example: password hashing in action
Example scenario
User creates the following password:
Step 1: Password input (Client side)
User enters password on the UI:
Step 2: Secure transmission
Password is sent over an encrypted HTTPS connection
Network interception cannot reveal the password
Step 3: Hashing and salting (server side)
Before storing, the system applies:
A unique salt
A one-way hashing algorithm (e.g. bcrypt / Argon2)
Resulting stored value (example):
This hash cannot be reversed to obtain the original password.
Step 4: Secure storage
Only the hashed password is stored
Original password is discarded immediately
Database example:
User email
Password hash
$argon2id$v=19$m=65536,t=3,p=4$…
3. Password verification example (sign in)
When the user signs in:
User enters password again
System hashes the input using the same algorithm and parameters
Hashes are compared
4. Security guarantees
This approach ensures:
❌ Passwords cannot be viewed by admins
❌ Passwords cannot be recovered if leaked
❌ Database breaches do not expose usable passwords
✅ Strong resistance to brute-force attacks
5. Why hashing (not encryption)
Hashing
Encryption
One-way
Two-way
Cannot be reversed
Can be decrypted
Ideal for passwords
Not recommended for passwords
Passwords must be hashed, not encrypted.
Additional notes
Hashing algorithms and parameters can be upgraded over time
Users do not need to take any action
Business accounts may apply stricter security policies
Summary
Passwords are never stored in plain text
Secure hashing with salting protects credentials
Even system administrators cannot recover passwords
Visual verification ensures safe authentication
Last updated