Security

Last updated: May 2026. This page is updated when the audit roadmap changes or when audit reports are published.

---

Fob is a closed-source app. We know what that means for trust: you can't read the code, so we have to earn it another way. This page is how we do that.

We publish our encryption architecture, our audit roadmap, and our disclosure process here, openly and in detail, so you can evaluate the claims before you trust us with your 2FA codes. The third-party security audit is committed post-launch; until then, the trust story is architecture you can verify and behavior you can verify, not a finished audit report.

---

Zero-knowledge architecture

Your codes never leave your device unencrypted. That's not a marketing claim. It's an architecture decision with specific consequences.

How vault encryption works

When you add an account to Fob, the secret key is stored locally in your device's secure hardware enclave (Android Keystore on Android, Secure Enclave on iOS). Your vault is encrypted on-device using AES-256-GCM before any data is written to disk or transmitted to our servers.

The encryption key is derived from your master password using Argon2id:

• Memory cost: 64 MB
• Iterations: 3
• Parallelism: 4
• Salt: 16 bytes, randomly generated per vault, stored alongside the encrypted blob

The derived key is used to encrypt your vault. The derived key itself is never stored anywhere: not on device, not on our servers. Each unlock derives it fresh from your password.

What the server stores

Our servers receive and store a single thing: an opaque encrypted blob. It looks like this to us:

userId: abc123
vaultBlob: <2KB-50KB of AES-256-GCM ciphertext>
version: 47
lastModified: 2026-04-10T14:23:11Z

That's it. The blob is meaningless without your master password. We store it so you can sync across devices and restore your vault if you lose your phone.

Data flow

Your device
  │
  ├─ Secret keys stored in Secure Enclave / Android Keystore
  │
  ├─ Vault encrypted with AES-256-GCM (key derived from master password via Argon2id)
  │
  └─ Encrypted blob ──────────────────────────────────────────► Fob servers (AWS S3)
                                                                   │
                                                                   │  Blob stored as-is.
                                                                   │  Server cannot read it.
                                                                   │
Your device ◄─────────────────────────────── Encrypted blob returned on sync
  │
  └─ Decrypted on device using derived key ──► Codes generated locally (RFC 6238 TOTP)

Nothing that happens between "blob returned" and "code displayed" involves our servers. TOTP codes are generated entirely on your device from the decrypted secret keys.

What we can and cannot see

Tag names are synced in plaintext so they appear correctly across devices. The mapping between tags and accounts lives inside the encrypted vault blob, so we know you have a tag called "work," we don't know which accounts are in it.

What happens if Cleargate Labs is subpoenaed

We comply with valid legal process. We'd have to. But here's what we could actually hand over: an encrypted blob and your email address.

We don't hold your master password. We don't hold a copy of your encryption key. We cannot decrypt your vault under any circumstances: not under subpoena, not under duress, not with AWS assistance. The math doesn't allow it.

If you want to verify this, review the architecture above. The design makes it structurally impossible for us to decrypt your data, regardless of what we're asked to do.

---

Security audits

Current status

Third-party security audit committed post-launch. Fob is pre-launch. The first third-party security audit is committed for after launch: we will book and run it once the product is live, on a timeline driven by revenue and an early-user-load milestone rather than a fixed calendar date.

We're publishing this commitment now so it's clear what we intend to do, and so you can hold us to it.

What the audit will cover

• OWASP Mobile Top 10. The standard checklist for mobile application security vulnerabilities.
• Encryption implementation. Independent verification that AES-256-GCM and Argon2id are implemented correctly, with appropriate parameters.
• Key storage. Verification that secrets are properly isolated in Android Keystore / iOS Secure Enclave and not accessible to other apps or processes.
• API security. Authentication, authorization, rate limiting, and injection vulnerabilities in the backend.
• Browser extension (if applicable at time of audit). Content script isolation, storage security, auto-fill injection safety.
• Transport security. TLS configuration, certificate handling, pinning decisions.
• Dependency audit. Known CVEs in third-party libraries.

Who will conduct it

A reputable third-party security firm with mobile application and cryptography specialization. We haven't selected the firm yet. We'll publish their name here when we do.

We don't intend to do a vanity audit. Where the auditor identifies real issues, our practice is to address them before shipping rather than minimize them.

What we'll publish

When the audit is complete, our practice is to post the report at this URL with findings, severity ratings, and our remediation response for each item. If a finding is too sensitive to publish before patching (for example, an active zero-day, an embargo requested by the researcher, or a legal restriction), we follow responsible disclosure norms: patch first, publish after. In limited cases, publication may be delayed or summarized rather than complete.

---

Responsible disclosure

If you find a security vulnerability in Fob, we want to hear from you.

How to report

Email security@fob.codes with:

• A description of the vulnerability
• Steps to reproduce it
• Your assessment of the impact
• Any relevant proof-of-concept (limited testing only, and don't access other users' data)

PGP key available on request. If you'd prefer an encrypted channel before sharing details, email first to ask.

What to expect from us

• Acknowledgment within 48 hours. You'll hear from a human, not an autoresponder.
• Status update within 7 days with our assessment and remediation timeline.
• Credit. If you want it, we'll acknowledge you publicly when we disclose the fix.

We don't have a formal bug bounty program yet. If your finding is significant, we'll discuss compensation.

Scope

In scope:

• Fob Android app (production builds)
• Fob iOS app (when available)
• Fob API (api.fob.codes)
• Fob browser extension (when available)
• fob.codes web properties

Out of scope:

• Denial-of-service attacks
• Social engineering of Cleargate Labs employees
• Attacks requiring physical access to an already-unlocked device
• Findings in third-party services we depend on (report those to the vendor directly)
• Automated scanning output without proof-of-exploitability

We ask that you give us reasonable time to fix issues before public disclosure. We'll do the same for you.

---

Encryption specifications

Why these choices

AES-256-GCM provides authenticated encryption. It detects tampering, not just confidentiality. A corrupted or modified vault blob will fail to decrypt rather than silently producing garbage data.

Argon2id is the current recommended password hashing algorithm (RFC 9106). It's memory-hard, which means brute-force attacks require substantial RAM, making large-scale offline attacks expensive even with specialized hardware. We chose Argon2id over PBKDF2 because PBKDF2 offers no memory-hardness guarantee.

TLS 1.3 eliminates the forward-secrecy gaps in older TLS versions. We don't support TLS 1.2 on our API endpoints.

SHA-1 TOTP default. Yes, the standard TOTP algorithm uses SHA-1 as its HMAC primitive. This is not a vulnerability in practice: TOTP codes are short-lived and rate-limited, and the collision attacks against SHA-1 don't apply to HMAC-SHA1. If your service requires SHA-256 or SHA-512 TOTP (uncommon), Fob supports those as well.

---

Export and continuity

Your vault is yours regardless of what happens to Cleargate Labs.

You can export your vault at any time from Settings › Export. The export is an encrypted file in a documented format, along with an unencrypted plaintext option if you want raw access. You don't need Fob to read your own export. Details on format and migration paths live at /import/google-authenticator and /import/authy.

If Cleargate Labs ceases to operate, your local vault continues to generate codes indefinitely. TOTP code generation is entirely offline. Your sync backup in the cloud would become inaccessible, but your export would remain usable.

We also document the vault encryption format on this page so that, in a worst case, a third party could build a decryption tool. (Format specification: to be published at launch.)

---

Related

For what we collect, where it lives, and how to control or delete it, read the privacy policy. To get on the launch list, head back to the homepage.

---

Questions

For security-related questions: security@fob.codes

For general support: support@fob.codes

For press inquiries about security: security@fob.codes with "press" in the subject line.

Cleargate Labs LLC · Overland Park, KS · fob.codes