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

1. User enters a password on the sign-up or sign-in page

2. Password is transmitted securely using HTTPS (TLS encryption)

3. The system hashes the password using a secure algorithm

4. 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:

Secure@123

Step 1: Password input (Client side)

User enters password on the UI:

Email: [e-mail]
Password: Secure@123

---

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):

$argon2id$v=19$m=65536,t=3,p=4$Q1NhbHQ$J0nA9F...

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
[e-mail]	$argon2id$v=19$m=65536,t=3,p=4$…

3. Password verification example (sign in)

When the user signs in:

1. User enters password again

2. System hashes the input using the same algorithm and parameters

3. Hashes are compared

Input hash == stored hash → access granted

---

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