Authfu

Trust

Security

How sign-in secrets are protected, what is encrypted, what is logged, and what we do not hold at all.

Last updated

01The design principle

The strongest security property of a passwordless system is the secret that does not exist. Authfu has no password to reuse, leak, phish in bulk, or reset. Removing passwords does not remove every account risk, but it removes an entire class of them.

02How sign-in is protected

A person signs in with a single-use magic link sent to their email address. The link is valid for minutes, not days. Once used or expired, it cannot create a session.

Two-factor comes first

If an account has TOTP two-factor authentication enrolled, Authfu verifies the code before sending any email. The server enforces this ordering. It is not just a step in the sign-in interface.

Knowing someone’s email address is therefore not enough to make Authfu send that person a sign-in message. The second factor must pass first.

Abuse and enumeration

  • Sign-in and second-factor attempts are rate-limited.
  • Public responses do not reveal whether an account exists. The response looks the same either way.
  • A failed second-factor attempt does not send a magic link and is recorded in the audit log.

03Passkeys

Passkeys use WebAuthn and replace the email step entirely. One passkey registered againstauthfu.app can sign the person in to every downstream application they use through Authfu.

A passkey is bound to the real origin. A lookalike site cannot ask for the credential and replay it, which makes passkeys resistant to phishing by construction. Authfu requires user verification, so the gesture proves possession of the credential and a local unlock such as a biometric or device PIN.

Nothing reusable to steal

Authfu stores only passkey public keys. A stolen passkey table gives an attacker no secret and no credential they can use to sign in.

04Encryption

Second-factor secrets

TOTP secrets are protected with AWS KMS envelope encryption. A customer master key in AWS KMS in us-east-2 wraps the data key, and the plaintext key never leaves AWS. A database dump by itself is not enough to read a TOTP secret.

Backup codes are SHA-256 hashed and can be used only once. Authfu compares a submitted code to its hash; it does not need to keep the original code.

In transit

Authfu uses TLS for traffic in transit. That includes sign-in, console, OIDC, and magic-link requests across Authfu’s public services.

05Tokens and OIDC

Downstream applications integrate with Authfu through standard OpenID Connect. ID tokens are signed with RS256. Authfu publishes the corresponding public keys through JWKS so an application can verify a token without sharing a signing secret.

  • Public clients must use PKCE with S256. Authfu rejects theplain method.
  • Authorization codes are short-lived and single-use.
  • Authfu supports nonce so a client can bind an ID token to the authorization request that produced it.
  • Sessions can be revoked centrally. Signing out everywhere ends access across the applications where that identity has a session.

06Account recovery

Losing a second factor starts a delayed, cancellable recovery. It does not immediately remove two-factor protection.

  • Recovery waits seven days.
  • Authfu emails a notice with a one-click way for the account owner to cancel the request.
  • After recovery, the new session cannot reach the console until two-factor is enrolled again.

Account recovery is the usual path around a second factor. The delay gives the real owner time to notice and stop a recovery they did not start.

07What administrators can and cannot do

Your users remain their own people

Building an application that uses Authfu does not give its developer control over the identities of the people who sign in. An app developer can never act as a user.

An organization administrator can start a time-boxed session as a member only when every condition below is true:

  • The organization controls a DNS-verified domain.
  • The member’s email address is on exactly that domain.
  • The administrator re-authenticates at the moment of use.
  • The administrator types a reason.
  • The session lasts no more than one hour.

Authfu notifies the member and writes the event to both audit logs. The administrator can never use this session to change the member’s credentials.

This boundary is structural. People have Authfu identities that they can use across applications; they do not become credentials inside an app developer’s tenant.

08Logging and audit

Authfu records sign-in and administrative events and makes them visible to the account. The log includes successful sign-ins, failed second-factor attempts, use of backup codes, session changes, and administrative actions.

Failures to decrypt a stored second-factor secret are also recorded. Submitted codes, plaintext TOTP secrets, encrypted TOTP secrets, and backup-code hashes are not written to audit metadata.

09Reporting a problem

Please read the vulnerability disclosure policy before testing or reporting a suspected security problem.

Send security reports to security@authfu.com. Include enough detail for us to reproduce the issue, but do not include secrets or personal data that are not needed to explain it.