Your password is plaintext for a few milliseconds on every login
Type a password into almost any login form and it travels, in cleartext, inside the TLS tunnel, to the server. TLS keeps it off the wire. But the server decrypts that tunnel and reads the plaintext before hashing it — and for those few milliseconds, your password sits in server memory. OPAQUE closes that window: it proves you know your password without ever sending it. The server stores a blob it can't reverse, and login becomes a cryptographic handshake instead of a credential you hand over. Beebeeb uses it.
That sounds like a small distinction. It changes what a breach can leak.
How a "secure" login usually works
Here is the standard flow most of the web runs on, including services with excellent security otherwise. You submit the form. TLS encrypts the connection. The server decrypts it, sees your password in the clear, runs it through bcrypt or Argon2id, and compares the result to the row in the database.
TLS does its job. Nobody on the wire reads your password — but the server does, and that brief plaintext moment is where things go wrong. A misconfigured request logger writes the POST body to disk, and now the password lives in a log file. That isn't hypothetical: it's how several large credential leaks have happened, at companies with strong security teams. An attacker with code execution on the auth box can read passwords as they arrive, no database crack required. A compromised dependency in the request path can skim them before they're ever hashed.
The salted hash table is the part everyone talks about. The plaintext-in-transit-and-in-memory part goes unmentioned, because for decades there was no practical alternative.
The OPRF: proving you know a secret without revealing it
OPAQUE's building block is an Oblivious Pseudorandom Function (OPRF) — a two-party computation. The server holds a secret key. You hold an input derived from your password. Together you compute one output, under a hard guarantee: the server learns nothing about your input, and you learn nothing about its key beyond that single output.
The trick is blinding. Your client maps your password to a point on an elliptic curve, then multiplies it by a random factor generated fresh for that login. It sends the blinded point to the server, which applies its secret key and returns the result. Your client divides the blinding factor back out. What remains is a high-entropy value that depends on both your password and the server's key — and the server saw only random-looking noise the whole time.
That value unlocks your account-level encryption material on the client. The server can't compute it without you. You can't compute it without the server's key. Your password is never on either side.
Why it survives a server breach
OPAQUE is an asymmetric PAKE (aPAKE), standardized in July 2025 as RFC 9807. The "augmented" part is what matters when someone steals the database.
In the conventional model, a stolen password table invites an offline dictionary attack: hash every candidate, look for matches. Worse, an attacker can pre-compute a giant lookup table before the breach and crack the whole dump the instant it lands. Salting slows the first pass; against GPUs it doesn't stop it.
OPAQUE is built to break pre-computation. Because the OPRF folds in a server-side key the attacker doesn't have, no useful table can be built ahead of time. After a compromise an attacker still faces a per-user offline grind, rate-limited by the password's own Argon2id stretching — and they recover nothing from network traffic or memory, because those values were never there to take. OPAQUE adds mutual authentication too: the server proves it's the real server, so a phishing endpoint can't quietly harvest a working credential.
This is shipping, not theory. WhatsApp uses OPAQUE to protect the passwords on its end-to-end encrypted chat backups, mixing the OPRF seed inside a hardware vault that locks out after too many wrong guesses.
How OPAQUE fits beebeeb's zero-knowledge model
Beebeeb is end-to-end encrypted and zero-knowledge by design. Your passphrase derives your keys on your device — Argon2id tuned to 256 MB and 4 iterations, then X25519 for key agreement and AES-256-GCM for file data, with keys zeroized from memory after use. The server holds ciphertext it cannot read.
OPAQUE is the login layer that matches that posture. Encrypting every file so the server can't read it, then handing that same server your password in plaintext on every sign-in, would be incoherent. With OPAQUE the credential that authenticates you obeys the same rule as your files: it stays on your device. You can layer passkeys and TOTP-based two-factor on top — OPAQUE handles the password leg, hardware-backed keys handle the second factor.
The honest limits
OPAQUE protects the password. It does not make a weak one strong. Pick password123 and an attacker who steals the credential file can still grind it offline — slower than against a raw SHA-256 dump, but not impossible. The Argon2id stretching buys you time; a long passphrase buys you safety. We can't recover that passphrase if you lose it, which is the literal cost of the server not knowing it — so we issue a BIP39 recovery phrase at signup.
OPAQUE is also newer than bcrypt-over-TLS, with a smaller pool of audited implementations, and we treat that honestly: an independent audit of our clients is planned, and the findings will be published. Our product clients — web app, CLI, mobile, desktop, and the core crypto library — are open source, so this integration is inspectable rather than asserted. (The server and this site stay private.)
If you want to watch a login that never transmits your password, Type a password, prove you know it, and nothing leaves the device.