Authentication & Limits
ApiVault enforces multi-factor authentication options, cryptographic one-time passwords, and strict attempt limits across all account access and decrypt endpoints.
Authentication Methods
The web application supports multiple authentication mechanisms designed for both developer convenience and high assurance:
| Method | Description |
|---|---|
| Google OAuth | Sign in with your Google account. Manage linked accounts in Settings → OAuth Connections. |
| Email & password | Traditional credentials with email verification and OTP password recovery. Set or change password in Settings → Security & MFA. |
| Passkeys (WebAuthn) | FIDO2/WebAuthn biometric credentials (Touch ID, Face ID, Windows Hello, YubiKey) for phishing-resistant sign-in. |
| TOTP 2FA | Time-based one-time passwords via an authenticator app (Google Authenticator, 1Password, Authy). |
| Email OTP Verification | 6-digit one-time password sent via email to verify account ownership and facilitate secure password resets. |
Passkeys can also serve as a second factor when MFA is enabled. The sign-in flow verifies the factor you actually use without exposing whether a particular email address has TOTP or passkey enrollment.
Email verification & OTP recovery
To prevent unauthorized account registration and enable secure self-serve password recovery, ApiVault implements cryptographically secure 6-digit One-Time Passwords (OTPs):
- SHA-256 Hashed Storage: Plaintext OTP codes are never stored in the database. Only SHA-256 hashes are persisted at rest.
- Time-Bounded Validity: OTP codes expire automatically after 10 minutes.
- Rate Limiting & Anti-Spam: A strict 60-second cooldown is enforced between code dispatch requests.
- Brute-Force Protection: Verification records automatically self-destruct after 5 failed attempts.
Sign-in & Vault-Key Attempt Limits
Failed authentication attempts are counted per account and per source address, so a stolen password cannot be searched for and a six-digit second factor cannot be guessed exhaustively. A completed sign-in clears the counter, so ordinary use — including mistyping a password a few times — never reaches a limit.
| Attempt Type | Limit | Counted per |
|---|---|---|
| Password sign-in | 10 failures per 15 minutes | Account and source address |
| Authenticator (TOTP) code | 5 failures per 15 minutes | Account and source address |
| Custom vault key (web, CLI, and MCP) | 10 failures per 15 minutes | Signed-in user and source address |
| Email OTP code | 5 failures, then the code is destroyed | Issued code |
Vault-key attempts are counted per user rather than per project, so one member of a shared project cannot exhaust the allowance for their team-mates. Requests that exceed a limit are answered with 429 and a Retry-After header.
The vault-key limit applies wherever a vault key can be supplied — the web vault-key prompt, the CLI's --vault-key flag and APIVAULT_KEY, and the MCP reveal_key, add_key and update_key tools. All three resolve vault keys through the same throttled code path, so no client has a faster route to guessing one. A correct key clears the counter, so a scripted apivault run or env export that decrypts many secrets in a row is never throttled.