[GH-ISSUE #14948] feat: Add zero-knowledge / PAKE-style login (e.g. SRP, OPAQUE, or WebAuthn) so passwords never leave the browser in clear text #32946

New Issue

GiteaMirror · 2026-04-25T06:47:11-05:00

GiteaMirror commented

2026-04-25 06:47:11 -05:00

Originally created by @sidhant-tibrewal on GitHub (Jun 13, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14948

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Open WebUI’s login form sends the user’s raw password inside a TLS-protected JSON body:

POST /api/auth/login

{ "email": "user@example.com", "password": "MySecret$123" }

This mirrors common practice on most web apps; TLS-in-transit plus server-side hashing (bcrypt/Argon2) is generally considered sufficient.

Why an extra layer matters in regulated networks

TLS termination & deep-packet inspection – Many company networks break and re-encrypt TLS at proxies, WAFs, or observability stacks. The decrypted request body can be:
• Logged verbatim by reverse proxies / APM tools
• Captured by insiders via packet captures on the internal network
• Written to application logs if sanitisation ever slips
• Zero-trust & “secrets never leave the endpoint” policies – Frameworks such as PCI DSS increasingly prefer that raw credentials never traverse any network hop, even inside a datacenter.
• User password reuse – Exposure of a single plain-text password inside corporate logs can cascade to other services if users reuse credentials.

Desired Solution you'd like

Implement (or provide pluggable support for) an authentication flow where the clear-text password never crosses the wire:

Client-side salted hash + nonce
Simpler stop-gap (PBKDF2/SHA-256)
SRP-6a
Password-authenticated key exchange with no server-stored plaintext-equivalent
OPAQUE
Modern asymmetric PAKE, IETF draft-29
WebAuthn / Passkeys
FIDO2 hardware-backed credentials

Any of these would satisfy “password never leaves browser in reusable form” requirements.

Alternatives Considered

No response

Additional Context

Impact / benefits

•	Reduces credential exposure in TLS-terminating environments.
•	Aligns with zero-trust and “defence in depth” security programs.
•	Makes Open WebUI easier to green-light for high-compliance sectors (banking, healthcare, defence).

Originally created by @sidhant-tibrewal on GitHub (Jun 13, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14948 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Open WebUI’s login form sends the user’s raw password inside a TLS-protected JSON body: POST /api/auth/login ```json { "email": "user@example.com", "password": "MySecret$123" } ``` This mirrors common practice on most web apps; TLS-in-transit plus server-side hashing (bcrypt/Argon2) is generally considered sufficient. **Why an extra layer matters in regulated networks** TLS termination & deep-packet inspection – Many company networks break and re-encrypt TLS at proxies, WAFs, or observability stacks. The decrypted request body can be: • Logged verbatim by reverse proxies / APM tools • Captured by insiders via packet captures on the internal network • Written to application logs if sanitisation ever slips • Zero-trust & “secrets never leave the endpoint” policies – Frameworks such as PCI DSS increasingly prefer that raw credentials never traverse any network hop, even inside a datacenter. • User password reuse – Exposure of a single plain-text password inside corporate logs can cascade to other services if users reuse credentials. ### Desired Solution you'd like Implement (or provide pluggable support for) an authentication flow where the clear-text password never crosses the wire: - **Client-side salted hash + nonce** Simpler stop-gap (PBKDF2/SHA-256) - **SRP-6a** Password-authenticated key exchange with no server-stored plaintext-equivalent - **OPAQUE** Modern asymmetric PAKE, IETF draft-29 - **WebAuthn / Passkeys** FIDO2 hardware-backed credentials Any of these would satisfy “password never leaves browser in reusable form” requirements. ### Alternatives Considered _No response_ ### Additional Context Impact / benefits • Reduces credential exposure in TLS-terminating environments. • Aligns with zero-trust and “defence in depth” security programs. • Makes Open WebUI easier to green-light for high-compliance sectors (banking, healthcare, defence).

GiteaMirror closed this issue

2026-04-25 06:47:11 -05:00

GiteaMirror commented

2026-04-25 06:47:12 -05:00

@tjbck commented on GitHub (Jun 13, 2025):

Interesting idea, would be nice to have it as an optional feature you can enable via env var, PR welcome!

@tjbck commented on GitHub (Jun 13, 2025): Interesting idea, would be nice to have it as an optional feature you can enable via env var, PR welcome!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#32946