The breach that didn't break anything
In 2024 a crew Mandiant tracks as UNC5537 logged into roughly 165 organizations' cloud data warehouses on Snowflake and walked out with terabytes of customer records — Ticketmaster, Santander, AT&T among them. No zero-day. No flaw in Snowflake itself; Mandiant found no evidence the platform was compromised. The attackers signed in with valid usernames and passwords harvested from infostealer malware on employee laptops, some of it dating back to 2020 and never rotated since. The accounts that got taken over shared one trait: no second factor. Username plus password was the entire door.
That is credential stuffing. Take a pile of leaked email-and-password pairs from one breach, spray them at a hundred other services with a bot, and cash in wherever someone reused a login. It is crude and fully automated, and it works for two reasons: people reuse passwords, and servers store something an attacker can replay.
Why a leaked password stays useful for years
When a service gets breached, the password table usually isn't plaintext anymore — the industry mostly learned that lesson. But "hashed" is carrying a lot of quiet weight in that sentence. Verizon's Data Breach Investigations Report has, across several years, tied the large majority of hacking-related breaches to stolen or weak credentials. Hashing doesn't save you because nobody brute-forces random strings. Attackers run lists of real passwords from earlier leaks against the stolen hashes, and weak or reused ones fall in seconds. The cracked plaintext then gets stuffed into every other account that person owns.
So one password leak yields two assets: a credential to crack, and proof that the human behind it is a reuser. Both have a long shelf life. The Snowflake credentials were years stale and still live.
Here is the part worth sitting with. A server breach is only catastrophic for your password if the server was holding something replayable to begin with. Most are. That hoard is the target. Remove it, and a database dump stops being a master key.
What does "the password never reaches the server" actually mean?
In a conventional login, your password — or something derived from it that can be replayed — travels to the server, which checks it against a stored hash. OPAQUE inverts that. It is an augmented password-authenticated key exchange, standardized in June 2025 as RFC 9807, and the password is used inside a cryptographic exchange that proves you typed the right secret without the password ever crossing the wire and without the server ever storing anything it could replay or crack.
The mechanics, at the level that matters for the threat: during registration, your client and the server run an oblivious exchange, and the server ends up holding an encrypted credential blob it cannot decrypt and cannot use to impersonate you. At login, both sides run a key exchange that only succeeds if your password was correct. The server never sees the password. It never sees a hash it could feed to a cracking rig.
Now replay the Snowflake scenario against that design. An attacker dumps the whole authentication database. What did they get? A pile of credential blobs that are useless without the password, and no password-equivalent to grind offline against a wordlist. Nothing to stuff into the next service. The single most valuable output of a server breach — a list of crackable, reusable secrets — simply isn't there to steal.
This is the model beebeeb uses for login. We pair OPAQUE with passkeys and TOTP-based two-factor auth, and account encryption keys are derived with Argon2id at 256 MiB of memory cost, so even the key-derivation path is expensive to attack. The specifics live on our security page.
Does OPAQUE login protect me, or the company?
Mostly the company's server — and by extension every other account you own, because it stops your credential from leaking out of this service into the stuffing pipeline. That is the honest framing. OPAQUE is not a shield around your individual account.
It does nothing about the original infostealer. If malware on your laptop reads your keystrokes or your browser's saved-password store, the attacker has your password directly, no server breach required. It doesn't stop a convincing phishing page that captures what you type into a fake login. It doesn't undo the fact that you reused that password somewhere that does keep a crackable hash. What it removes is one specific, enormous attack surface: the server-side hoard that turns one company's bad day into a hundred companies' account-takeover spree.
So the unglamorous advice still holds, and any vendor claiming their login alone makes the rest optional is overselling. Use a unique password per service — a password manager makes that free, and reuse is the whole reason stuffing works. Turn on a second factor; the Snowflake accounts that survived were the ones with MFA, and passkeys are stronger still because there's no shared secret to phish. Keep your endpoint clean, since most stuffing fuel comes from infostealers on the device, not clever cryptanalysis. OPAQUE is the one piece of that stack the service has to build for you; the rest lives on the endpoint, which is exactly where the honest line lands.
Why most providers still send the password
Because conventional login is easy, well-trodden, and "we hash passwords" reads fine in a trust-center page. A salted Argon2id hash is genuinely good engineering, far better than what plenty of breached companies were doing. But it is still a stored, attackable artifact. The gap between a strong hash and OPAQUE is the gap between making the target hard to hit and removing the target from the room. For a service whose entire premise is that we cannot read your files — beebeeb is end-to-end encrypted and zero-knowledge on every tier, including the free one — leaving a crackable password hash on the server would be the loud contradiction.
Encryption at rest and "we hash your passwords" are the floor, not the ceiling. The question worth asking any provider you hand your data to is what they've built that a database dump can't undo. You can see how OPAQUE fits with configurable version retention, encrypted sharing, and the rest of the account model on our features page.