Cybersecurity 28 August 2026 10 min read A better password is still a password By Old Forge Technologies 6 reads Contents # A better password is still a password I went back to Cloudflare's write-up of OPAQUE this week, and for about an hour I was completely sold. The pitch is hard to argue with. Your password never leaves your browser. Not hashed on the wire, not held in memory on the server for the few milliseconds it takes to compare a hash, not sitting in a log line because somebody left debug logging on in production. The server genuinely never sees it, and it still manages to authenticate you. If you have ever had to write the incident email that begins "we have no evidence that passwords were accessed", you will understand the appeal of a design where that sentence is a mathematical fact rather than a hopeful reading of your log retention. So I did what I always do with an idea this attractive: I opened the Wegweiser codebase and tried to work out where it would go. What follows is why it is not going anywhere, and why the reasoning turned out to be more interesting than the answer. ## What OPAQUE actually does Strip away the cryptography and OPAQUE is a way for two parties to agree that they both know a secret, without either of them handing the secret over. At registration your browser and the server run something called an oblivious pseudo-random function. The server holds a per-user key. Your browser holds the password. Together they produce a value that neither side could have produced alone, and critically, the server learns nothing about your password in the process. Your browser uses that value to lock a small encrypted envelope containing a private key, and ships the envelope to the server for safekeeping. At login the dance repeats. Your browser rebuilds the same value from the password you just typed, unlocks the envelope, and uses the key inside to prove itself. Wrong password, envelope will not open, no proof. Two properties fall out of this, and both are real. The server never holds your password in any recoverable form. Because the server-side salt is never revealed to a client, an attacker who steals your user table cannot start grinding it until after the breach. No precomputed rainbow tables, no head start. That is elegant work. It is also, as of writing, still an IRTF draft rather than a published RFC, which matters for the argument below. ## The question I should have asked first Here is where I caught myself. I had spent an hour on "how would I build this" without once asking "what does this replace". Wegweiser already ships passkeys. Not on a roadmap, not behind a flag. WebAuthn, discoverable credentials, so there is no username field at all, with user verification required so the authenticator insists on a fingerprint, a face or a PIN before it will sign anything. Sign in with Windows Hello, Touch ID, a YubiKey, or the password manager you already use. Passwords also still work, because passkeys are an option and not yet an ultimatum. There is two-factor with authenticator apps and backup codes, and Microsoft single sign-on for the customers whose identity lives in Entra. Now put OPAQUE next to that honestly. OPAQUE is the best possible answer to the question "how do we keep passwords safely". Passkeys answer a different question: "why are we still keeping passwords". The private key lives in a secure element and never leaves it. There is nothing to phish, nothing to reuse across sites, nothing to type into a convincing replica of my login page. OPAQUE protects the password beautifully, but the user still has one, still chose it badly, and still uses it on four other services. Adopting OPAQUE would mean investing significant effort in making the weaker of my two authentication paths less weak. ## What it would cost, specifically The costs are not abstract, which is what settled it. **There is no migration path.** The draft is explicit that existing password hashes cannot be converted. OPAQUE registration is interactive by nature, so every single user would have to re-enrol their password through the new flow. That means running both systems side by side for months, which means twice the authentication surface to keep correct during the exact period when it is least well understood. **The server loses the ability to enforce a password policy.** This one surprised me. If the server never sees the password, it cannot check length, it cannot check complexity, and it cannot check the password against a breach corpus. All of that moves into browser JavaScript, which is to say all of it becomes optional for anyone willing to skip it. I would be trading a protection I actually use for one I do not need. **Login becomes dependent on JavaScript.** Today my login form degrades to an ordinary form post. Under OPAQUE, if the crypto bundle fails to load, nobody signs in at all. **Password reset gets considerably harder.** At the moment a reset writes a new hash. Under OPAQUE it becomes a full re-registration handshake conducted in the browser off the back of a reset token. **None of it touches single sign-on**, which is where a good proportion of MSP users live anyway. Then there is the part nobody likes saying out loud. Server-side implementations are thin, the client side wants a WebAssembly bundle, and the specification is not finished. I would be introducing a substantial quantity of young cryptographic code into the one code path where a subtle bug is not a bug but a total compromise. The bar for that is not "this is clever". The bar is "this solves a problem I actually have", and I could not clear it. ## The more interesting question Authentication was the easy half. The half I actually wanted to think about was this: if the browser can derive a secret the server never learns, could you use that secret to encrypt the customer's data? The mechanism exists. OPAQUE specifies an export key, a per-user value derived during login that the server never sees. It is exactly the primitive behind password manager architectures, where the vendor genuinely cannot read your vault because the key to it never reaches them. It is the reason a breach of such a vendor's servers need not mean a breach of your vault. So could Wegweiser encrypt device telemetry, health scores and AI conversations under a key derived from the operator's password? No. Not because it would be hard, but because of what Wegweiser is. **The data does not belong to a user.** It belongs to a tenant. Ten engineers at the same managed service provider all need to read the same device record, and a key derived from one person's password cannot decrypt data that ten people need. You can work around this with envelope encryption, wrapping a shared key once per user, and people do. Then the eleventh engineer joins, or somebody forgets their password, and you need a colleague who currently holds the unwrapped key to be online and available to re-wrap it. That is a support burden nobody wants at four in the afternoon on a Friday. **Nobody is logged in when the work happens.** This is the one that actually kills it. Wegweiser's value is that roughly forty analysers run continuously against incoming agent data, scoring hardware, patches, authentication, network behaviour and the rest, rolling those scores up from device to group to organisation to tenant. Every one of them runs on a schedule with no user session anywhere near it. Encrypt the data under a key that only exists in a logged-in browser and the entire analysis pipeline goes blind. Give the background workers a copy of the key so they can carry on working, and the server holds the key again, at which point you have all of the complexity and none of the guarantee. **The analysis needs plaintext regardless.** Device summaries go to a language model to be interpreted. Encrypting data end to end and then decrypting it to post to an inference endpoint is not security, it is decoration. **Aggregation needs plaintext too.** Health scores are averages and sums across thousands of rows. You cannot average ciphertext. The whole product is that rollup. Export keys are for vaults. A vault's job is to hold something and hand it back to exactly one person. Wegweiser's job is to read everything continuously, correlate it, and tell a team of people what it found. Those two designs want opposite things from encryption, and no amount of clever protocol reconciles them. ## Where the idea does earn its place There is one category where the logic holds. Not bulk data, but the small set of credentials a platform holds on a customer's behalf: API keys for AI providers, mail credentials, agent enrolment secrets. Small, sensitive out of all proportion to their size, and catastrophic in a way telemetry is not. Wegweiser keeps those in an encrypted local vault, authenticated encryption with a properly slow key derivation, and that part is sound. The interesting question is not the cipher, it is where the key that opens it lives. A key sitting on the same host as the ciphertext it protects means one compromise gets both. That is a real design tension and worth revisiting properly. The honest fix there, though, is not OPAQUE. It is moving the master key off the machine entirely, into a hardware-backed key service or a split unseal that needs more than one holder to reconstruct. Boring, well understood, and it addresses the actual weakness rather than an adjacent one. ## If you do want keys derived from a person There is a better road, and it is one I am already on. WebAuthn has an extension called PRF, built on the authenticator's hmac-secret capability. It gives you the same primitive OPAQUE's export key gives you: a stable per-credential secret the server never learns, usable as an encryption key. It comes from the passkey the user already has. It needs no new cryptographic library, no WebAssembly bundle, and no password to be phished in the first place. Support is not yet universal across every browser and authenticator combination, but where it exists it is native, and the direction of travel is clear. If the goal is a key derived from user authentication, and one day it might be, the passkey is the sensible place to derive it from. ## The part worth keeping I want to be clear that OPAQUE is good work. The cryptography is sound, the problem it solves is genuine, and in a system built today with passwords at its centre and no realistic route to passkeys, it would be a serious contender. But my conclusion was not "OPAQUE is bad". It was "I already made this decision, I just made it by shipping passkeys instead of by writing an article about it." The discipline I keep having to relearn is that reading about an excellent idea and adopting it are separate acts, with a question in between: what, in my system, gets better. Sometimes the answer is nothing, because the problem was solved a different way already. The hour was not wasted. I now know precisely why my authentication looks the way it does, which is not the same as knowing that it works. The best answer to "how do we store passwords safely" is still to have fewer of them. --- *Wegweiser is my intelligence layer for managed service providers. Release notes and product announcements live on [the Wegweiser blog](https://app.wegweiser.tech/blog); this journal is where I think out loud about the decisions behind them.*
