Passwords

DarkAuth supports signed-in password changes and email password reset. Both flows are designed around OPAQUE, so changing a password means replacing the OPAQUE authentication record rather than storing a conventional password hash.

Changing a password while signed in

Users can change their password from account settings. DarkAuth may ask for the current password or an additional verification step before the change is accepted. After the password is changed, future logins use the new OPAQUE record.

For applications that depend on zero-knowledge key material, a signed-in password change can preserve recovery continuity because the user can prove access to the old password-derived material during the flow.

Email password reset

Email password reset is available only when administrators enable SMTP and password reset settings. The public request flow intentionally returns the same generic message whether an account exists or not. That prevents attackers from using the reset screen to discover valid email addresses.

The user flow is:

1. Open the forgot-password page.
2. Enter an email address.
3. If the account exists and policy allows it, receive a reset email.
4. Open the reset link.
5. Complete a new OPAQUE password setup.
6. Return to login.

The reset flow does not automatically sign the user in. Existing MFA policy still applies on the next login.

Why reset links expire

Reset links are single use and time limited. Creating a new reset token consumes other active reset tokens for the same user. A successful reset also invalidates active user sessions, authorization codes, and pending authorization requests.

This means a password reset is both an account recovery event and a security boundary. Anything still authenticated under the old password should be cleared.

Zero-knowledge recovery limits

An email password reset restores account access. It does not automatically decrypt data that was wrapped under the old OPAQUE export key.

If an application stores user data under a DRK, the user may need an additional recovery flow after signing in with the new password. If the old password is not available and the application has no other recovery method, older encrypted content may remain unavailable.

This is an important tradeoff. DarkAuth can avoid server-side custody of the key, but that also means the server cannot simply recover encrypted user data by sending an email.