> For the complete documentation index, see [llms.txt](https://oten.gitbook.io/identity-support/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://oten.gitbook.io/identity-support/user-guide/account-management/authentication/secure-password-hashing-and-storage.md).

# 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: user@example.com
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                    |
| ------------------ | -------------------------------- |
| <user@example.com> | $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