# 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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://oten.gitbook.io/identity-support/user-guide/account-management/authentication/secure-password-hashing-and-storage.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.