Zero-Knowledge

Zero-knowledge features are easiest to understand as a key custody decision. DarkAuth can help applications authenticate users without the server learning the password, and it can help trusted apps receive a user-held Data Root Key without storing that key in plaintext on the server.

What DarkAuth protects

DarkAuth uses OPAQUE for password authentication. In the OPAQUE flow, the password is not sent to the server. The server stores an OPAQUE record that lets it participate in future logins without learning the password.

For zero-knowledge enabled apps, the browser can derive key material after login, unwrap a user DRK, encrypt that DRK to the app’s ephemeral public key, and deliver it through the URL fragment. The server stores only wrapped key material and a hash binding for the handoff.

What this does not protect

Zero-knowledge does not mean the browser never sees the key. The browser code needs the key to decrypt data or hand it to an application. That means users still rely on:

• The JavaScript served by DarkAuth.
• The JavaScript served by the application.
• The browser and operating system.
• Browser extensions and device security.
• Correct application behavior after it receives the key.

If any of those are compromised, a key may be exposed while it is in use.

Why reloads can matter

The default hosted-web profile keeps the DRK in memory. Memory-only custody reduces persistent browser storage risk, but a page reload loses the key. A well-designed app should start a fresh authorization request and get a new encrypted handoff when it needs the DRK again.

If the DarkAuth session is still valid and the necessary client-side material is available, this may not require a full password prompt. If not, the user may need to sign in or complete a step-up flow again.

Password reset tradeoff

Email password reset restores account access. It does not magically recover encrypted data that depended on the old password-derived key. If an app relies on DRK-protected data, it should explain its recovery model clearly before users need it.

The benefit is that the server is not silently holding the user’s decryption key. The tradeoff is that recovery requires explicit design.