SRP avoids sending the password in the login exchange; it does not make a stolen verifier harmless.
Secure Remote Password, or SRP, lets a client and server authenticate using a password without sending that password in the normal protocol exchange. It can reduce exposure to a server that would otherwise receive the password during login.
It does not remove every password-related secret from the server. The server keeps a verifier, and a stolen verifier can support offline password guessing. That distinction is essential when assessing claims about “zero-knowledge login.”
What changes compared with a conventional password login?
In a conventional design, the client sends the password over an authenticated TLS connection. A well-designed server compares a suitable salted password hash, avoids logging credentials and applies protections against guessing. TLS protects the connection; a password hash protects the stored credential differently.
SRP changes the exchange. During enrolment, the system establishes salt and verifier material. At login, both sides use fresh protocol values and their respective secrets to establish and confirm shared key material. The client uses the password; the server uses its verifier. An honest client does not submit the password itself as the login payload.
The SRP specification in RFC 2945 explains the protocol's foundation. Later profiles and implementations need their exact parameters and message checks reviewed; calling a design “SRP” does not establish that every implementation choice is sound.
| Question | Conventional password-over-TLS login | Correctly implemented SRP exchange |
|---|---|---|
| Does the application server receive the entered password at login? | Normally yes | Not as part of the protocol exchange |
| What sensitive authentication material is stored? | Typically a salted password hash | Salt and a password-derived verifier |
| Can a stolen database support offline guessing? | Yes, depending on stored material | Yes, stolen SRP verifier material can support guessing |
| Does it protect against a keylogger? | No | No |
| Does it encrypt message history automatically? | No | No |
Why a stolen verifier still matters
RFC 5054 section 3.3 explicitly discusses stolen verifiers. It explains that a verifier can enable an attacker to masquerade as the server and conduct dictionary attacks to recover the password.
The important distinction is that the verifier is not simply a reusable client login token. That does not make it harmless. An attacker can test candidate passwords against the stolen material rather than solving a discrete-logarithm problem for every possible secret. A weak or reused password remains a serious risk.
Online rate limits can slow attempts against a live service, but they do not govern computations performed on a stolen database. Database protection, careful password processing and strong unique passwords remain relevant.
What SRP does not protect
A compromised endpoint: Malware can capture the password before the protocol starts or steal an authenticated session afterwards.
A malicious login page: If the page asking for the password is itself hostile, it can send the entered text elsewhere. A web application still needs a trustworthy delivery path.
All recovery paths: An email, SMS or support flow that grants account access has its own requirements. The strongest normal login method can be undermined by a weaker fallback.
Every active network attack: Protocol parameters, input validation, mutual confirmation and the surrounding authenticated connection matter. Do not replace a deployment's prescribed TLS protections with the slogan “the password never travels.”
Metadata or chat encryption: Authentication answers whether a session should be admitted. It does not determine which conversation records exist or who holds message-decryption keys.
How Livara separates login from identity recovery
Livara's security overview describes SRP authentication separately from its LVR1 messaging protocol. It also documents a version-7 encrypted identity backup protected by a distinct random 256-bit recovery key.
The backup is sealed before upload and restores cryptographic identity, not chat history. Knowing an account password alone does not restore those encryption keys. Conversely, a statement that support cannot reconstruct an encryption secret does not establish that no account-management action or password-change process can exist.
The threat model also keeps device compromise and visible communication metadata within scope. SRP should not be used to relabel the entire service as “zero knowledge” about every aspect of a user's activity.
A practical assessment checklist
For a user, choose a unique strong password, protect the device, keep recovery material in an appropriate separate location and understand how sessions are revoked. Do not type a secret into an untrusted site merely because it claims to use SRP.
For a technical reviewer, request the exact protocol profile, password-to-verifier processing, input validation, failure handling, enrolment flow and reset design. Review the client and server together. Include tests for invalid public values, replay and interrupted sessions rather than relying solely on a successful login test.
SRP is a useful tool for limiting password disclosure during authentication. Its value is clearer when its real benefits are described alongside verifier theft, endpoint compromise and recovery risks, rather than presented as the end of password security problems.
