Login & MFA — bRRAIn Docs

Authentication on bRRAIn — passwords, MFA, sessions, SSO, and session security.

Login & MFA

Authentication is the front door. This page covers how bRRAIn authenticates members and how to harden it.

Password authentication

Storage

Passwords are stored as Argon2id hashes with per-user salt and bRRAIn-wide pepper. We do not store raw passwords.

Hash parameters tune to current security recommendations and are revisited annually.

Requirements

We enforce:

  • Minimum 12 characters.
  • Cannot match the user's email or display name.
  • Cannot match any of the most-common-password lists (we check against a large corpus).
  • Cannot match any of the user's previous passwords (last 10).

We don't enforce composition rules (no "must contain a digit") because they reduce real password strength. Length is what matters.

Reset

Forgot-password emails carry a one-time link valid for 60 minutes. Reset triggers MFA challenge if MFA is enrolled.

Sign-in after reset invalidates all other sessions.

Rotation

We don't force routine password rotation. Forced rotation reduces password quality (people pick easier passwords to remember). We do force rotation on:

  • Suspected exposure (your email appeared in a breach corpus).
  • Sovereign-initiated reset.
  • Significant authentication anomaly.

Multi-factor authentication

Channels

| Channel | Protocol | Best for | |---|---|---| | TOTP | RFC 6238 | Strong, simple, offline-capable. Recommended. | | WebAuthn / Passkey | WebAuthn standard | Strongest. Recommended for security-sensitive members. | | SMS | OTP via your phone number | Backup only. SIM-swap risk. | | Email (recovery email) | OTP via secondary email | Backup only. |

We recommend at least one strong factor (TOTP or WebAuthn) plus one backup channel.

Recovery codes

When you enroll TOTP we issue 10 single-use recovery codes. Save them in your password manager or print them. Each is one-shot.

MFA enforcement

Organizations can enforce MFA from Console → Settings → Authentication:

  • Off (not recommended).
  • Required for Sovereigns and Architects only.
  • Required for all members.

Enforcement applies on next sign-in.

Step-up authentication

Sensitive actions can require fresh MFA even within an existing session:

  • Changing your password.
  • Adding or removing an MFA channel.
  • Editing billing.
  • Triggering a danger-zone action.

Step-up is configurable; defaults are sensible.

Sessions

Lifetime

Default session lifetime is 30 days. Configurable per organization (Console → Settings → Authentication).

Sessions expire on:

  • Their natural expiration.
  • Sign-out.
  • Password reset.
  • Significant authentication context change (IP geographic move with no recent activity).

Cookies

Session cookies are:

  • Scoped to *.brrain.io (so you stay signed in across surfaces).
  • HttpOnly (no JavaScript access).
  • Secure (HTTPS-only).
  • SameSite=Lax (defends against most CSRF).
  • Refreshed on each request to extend the session.

Device list

Each member can see their active sessions under Account → Security → Active sessions:

  • Device, browser, IP, last-used time.
  • Revoke any session with one click.
  • Revoke all but current.

Single sign-on (SSO)

SSO via SAML 2.0 is available on Business and Enterprise tiers. Supported IdPs:

  • Okta
  • Microsoft Entra ID (Azure AD)
  • Google Workspace
  • OneLogin
  • JumpCloud
  • Ping Identity
  • Generic SAML 2.0

OIDC and OAuth 2.1 are also supported for IdPs that prefer those.

Configuration is documented in Console: Members & roles.

When SSO is enabled and enforced, members of your domain skip the password screen entirely.

Service accounts

Bots, CI, and SDK callers use service-account credentials:

  • Long-lived bearer tokens, scoped to specific roles and zones.
  • Or short-lived OIDC tokens (recommended for CI environments).
  • Configurable rotation policies.
  • All actions logged with the service account as actor.

Service accounts can't have MFA. Their security is controlled through scope minimality and rotation.

Anomaly detection

We watch for patterns that suggest compromise:

  • Sign-in from a new geography with no prior activity.
  • Multiple failed sign-in attempts.
  • Use of leaked credentials (we check against breach corpora).
  • Session hijack indicators (cookie used from unexpected device).

Anomalies trigger:

  • A step-up MFA challenge.
  • A notification to the affected member.
  • A high-severity audit event for the organization.

Repeated anomalies on a member trigger automatic account suspension pending review.

Account lockout

After 10 failed sign-in attempts in a 15-minute window, the account locks for 15 minutes. Locked accounts can be unlocked by:

  • Waiting out the lockout window.
  • Sovereign action.
  • Verified-identity reset via support.

Where to next