Skip to content

Better Auth Zero Access · by Railman

Proton Mail–style security in your own app.

Early Better Auth plugins for zero-access vaults, sealed 1:1 chat, and step-up. Direction: keys stay in the browser; your server stays blind.

See Elevate, Vault, ChatChoose a use case

Publishing as @railman · pre-1.0 · review before production use

ceremony cross-sectionYour server stays blind. Only wraps cross the wire.

What this is

A foundation for zero-access patterns you own.

We are building toward the shape of security people know from Proton Mail — browser-held keys, a blind server — as open Better Auth plugins. Not a claim of parity. A direction.

Built by Railman. Elevate, Vault, and Chat each do one job. Passkey and PRF anchor Vault and Chat; Elevate can stand alone.

01

Prove

Ask for fresh proof before sensitive actions.

02

Unlock

Keep encryption keys in the browser, not on your server.

03

Seal

Store ciphertext and message envelopes without plaintext.

How the suite fits together

Elevate stands alone. Vault and Chat share a passkey core.

The suite is passkey-centered. Elevate is the independent path when password or TOTP step-up is all you need.

existing foundationBetter Auth sessionuser · session · factors
Passkey-centered stack

Hardened passkey + PRF

enhancePasskey()

Vault unlock produces the client-held material that anchors Chat.

Elevate

Ask again before the action matters.

Elevate gives Better Auth apps a short, server-verified approval window for sensitive actions. It works without passkeys, PRF, a MEK, or zero-access storage.

Protect account changes

Require fresh proof before ownership transfer, deletion, or security settings.

Approve billing actions

Put plan changes, payment methods, and invoices behind a short sudo window.

Guard recovery flows

Re-authenticate before users enroll, rotate, or disable recovery methods.

Open admin mode

Grant privileged tools for minutes instead of the full login session.

Request pathFresh proof follows the action, not the whole session.
  1. 01Sensitive requestAccount, billing, recovery, or admin action
  2. 02Fresh proofPassword, TOTP, or passkey
  3. 03Approval claimServer-signed and short lived
  4. 04Action allowedProtected route verifies the claim

No vault key, PRF output, or plaintext enters this path.

smallest setupSession provenance + step-up

Enough for account controls. Nothing here can open a vault.

loginFactors()+twoFactor()+elevate()
Get startedTry the lab

Choose the proof

Use the method that matches the risk.

Start with password re-entry and TOTP. Add passkey step-up when the same WebAuthn credential should protect login and sudo.

password

Password re-entry

Use when password confirmation fits the action’s risk level.

TOTP

Authenticator code

Verify a fresh Better Auth two-factor code for stronger proof.

passkey

Passkey step-up

Use when the same WebAuthn credential should protect login and sudo.

Passkey

Harden WebAuthn where you use it.

@railman/auth-zero-access-passkey freezes RP and origin options, requires user verification, and pairs login with the counter guard.

Passkey package guide →
01

Harden Better Auth passkeys

Ship the secure options together instead of rebuilding stock WebAuthn settings by hand.

02

Share one counter guard

Give Elevate the same controller when passkey step-up is enabled.

03

Unlock the vault

Use PRF helpers when Vault needs browser-held key material.

Vault and Chat keep secrets on the client side of TLS.

Elevate does not need this. Zero-access starts here.

Vault

Keep keys in the browser. Store only wrapped material.

@railman/auth-zero-access stores wraps, recovery records, policy metadata, and optional relay data. It never receives vault secrets.

browser onlyMEKPRF outputVault passwordRecovery phrasePlaintext
may cross TLSwrapped MEKKDF parameterssealed envelopespublic proofs
server storesWrap rowsMEK metadataHMAC claimsRate limitsFingerprints

In your product

Encrypt user data without holding their keys.

The server package stays blind. @railman/zero-vault handles create, unlock, reset, and re-enrollment in the browser.

Server package →Browser package →

Encrypt user records

Seal notes, files, credentials, and settings with a client-held MEK.

Unlock locally

Use passkey PRF or a vault password in the browser. The server returns wraps, not keys.

Recover safely

Reset access with a recovery phrase and re-enroll daily methods without exposing the MEK.

Grant and revoke

Manage wrapped access methods while the server stores only metadata and ciphertext.

Chat

Seal 1:1 messages on a passkey-centered vault identity.

experimental

@railman/zero-e2e adds X3DH-style session setup and a Double Ratchet. It is not a group or multi-device messaging platform.

Chat package guide →

What Chat does

Private delivery, peer verification, and rotating keys.

1:1 delivery pathPlaintext stops at the browser boundary.
Identity foundation
PasskeyPRFVault unlockIdentity seed

Zero-e2e consumes the seed; the Vault path performs the passkey and PRF ceremonies.

Client AEncrypt
  • Vault-derived identity seed
  • Ratchet state
  • Message plaintext
Relay
  • Public prekey bundle
  • Sealed envelope
  • Routing metadata
Cannot read message plaintext
Client BDecrypt
  • Vault-derived identity seed
  • Ratchet state
  • Message plaintext

Session setupX3DH-style prekey exchange

Peer checkSafety-number fingerprint

After deliveryDouble Ratchet rotates message keys

Compare the paths

Same suite, different security jobs.

Elevate can run independently. Vault uses the passkey foundation, and Chat extends the unlocked Vault identity.

Core

Elevate

@railman/auth-elevate
Best for
Account, billing, recovery, and admin actions
User proof
Password or TOTP; passkey is optional
Client side
No encryption key required
Server side
Verifies a fresh approval claim
Read the Elevate guide →
Core

Vault

@railman/auth-zero-access
Best for
Notes, files, credentials, and private settings
User proof
Passkey-centered; PRF, vault password, or recovery unlock
Client side
MEK and plaintext stay in the browser
Server side
Stores wraps, metadata, and ciphertext
Read the Vault guide →
Experimental

Chat

@railman/zero-e2e
Best for
Sealed direct messages between two users
User proof
Identity seed supplied by the unlocked Vault
Client side
PRF path anchors identity; message keys rotate on the client
Server side
Relays sealed envelopes and routing data
Read the Chat guide →

Also useful

Packages that make the flows above easier.

Passkey hardens WebAuthn. Login Factors tracks how the session was established. Zero Vault is the browser UX for Vault.

Passkeys

@railman/auth-zero-access-passkey

enhancePasskey()

Hardens Better Auth passkeys and supplies the counter guard and PRF helpers.

Sessions

@railman/auth-login-factor

loginFactors()

Records how the user signed in and gates routes that need a stronger factor.

Browser vault

@railman/zero-vault

createVaultClient()

Handles create, unlock, recovery, and re-enrollment in the browser.

Compare all packages →

Try it

Three labs you can open now.

Hosted data is disposable. Use a lab to see the flow before you wire it into your app.

Step-up lab

Elevate

Try password, TOTP, and optional passkey proof without a vault or MEK.

Open Elevate →Vault lab

Vault

Create, unlock, seal, recover, and inspect exactly what crosses the wire.

Open Vault →E2E lab

Chat

Test sealed 1:1 messaging and safety-number fingerprints.

Open Chat →

Docs

Start with the smallest useful setup.

Prefer a use case first. Extended reading covers WebAuthn/PRF, crypto primitives, and design rationale.

Security is hard. We seek an open foundation.

Pre-1.0 plugins for step-up, zero-access vaults, and sealed chat. Review before production. Help harden it in the open.