Security depends on the key, the browser, and the real sign-in page

Threat model: which attacks the design tries to limit

The product separates a temporary guest generator from a member Vault with encrypted synchronization. Its design addresses database leakage, backup exposure, sensitive logging, cross-account authorization, replayed changes, stolen sessions, deleted device paths, and conflicting offline edits. The browser generates codes from secrets it has been given. Member items are encrypted locally before ordinary sync. These boundaries reduce the reason for server components to hold usable plaintext seeds.

This is not a claim that a compromised server can never influence the client, or that encrypted storage defeats every attacker. The original website still controls whether a TOTP is accepted; its login page, recovery process, rate limits, and factor configuration remain independent. For sensitive accounts, study both the service's security options and the local authenticator's failure modes.

A TOTP seed is more sensitive than today's numeric code

A setup key or export QR can reproduce future values as long as its original website enrollment remains active. A current six- or eight-digit code is derived for one time interval; it may still be phished immediately, but it is not a replacement for possession of the long-lived seed. This is why the QR capture flow runs client-side and why the logging contract forbids secret-bearing otpauth URIs, migration payloads, OTP values, passphrases, and recovery keys.

Keep original enrollment QRs off shared screenshots, public issue trackers, and messaging channels. When you suspect a seed has been copied, rotate or remove that original site's TOTP enrollment through its security settings. Removing the Vault's local copy cannot invalidate a matching copy on an attacker-controlled device.

How encrypted Vault keys are separated

The browser is designed to create a random Data Encryption Key, or DEK, to protect individual Vault records using authenticated AES-GCM encryption. Instead of persisting that DEK as plaintext on the server, it is wrapped into separate versioned key slots. A Vault passphrase can derive a wrapping key under an approved Argon2id profile; recovery material supplies another independent route. Each key's purpose is different from Google identity and from the short-lived OTP code.

Associated integrity data and record-bound information help detect altered or misplaced ciphertext before decryption. The user experience does not require the server to decrypt issuer names, account labels, notes, or seeds during sync. However, the chosen key-derivation cost must be measured on real target hardware, and the G04 acceptance gate remains separate from source-code verification; avoid assuming every target browser already has an approved profile.

Browser compromise is a serious boundary

A legitimate application must display a decrypted code somewhere the user can read it. Malware, compromised page JavaScript, a hostile browser extension, or someone controlling that browser session can attempt to observe secrets while the Vault is unlocked. Content Security Policy, dependency controls, safe rendering, and narrowed logging reduce parts of this attack surface, but they do not magically turn an attacker-controlled runtime into a trusted computer.

The application attempts to clear decrypted references on lock, inactivity, prolonged backgrounding, page departure, sign-out, and account switching. These are useful lifetime limits, not proof that physical RAM has been overwritten. Web Crypto non-extractable keys are a browser primitive, not a guarantee of a secure element, hardware backing, or resistance to malware that can invoke an unlocked key.

Protect against real-time phishing and code relay

TOTP improves many password-based flows by requiring a second credential, but it does not bind a submitted numeric code to the legitimate website's origin. A real-time phishing page can request the password and current code, then immediately relay them to the real website. A familiar logo or authenticator label does not validate the page asking for the digits. Carefully verify the destination address and be suspicious of repeated code prompts.

Where available, passkeys and FIDO security keys offer phishing-resistant origin-bound authentication. They are not included as 2FASync's TOTP engine features, but they may be appropriate factors for the underlying website. Keep the original service's recovery options up to date, and understand how it handles suspicious account recovery requests.

Trusted devices and revocation have limits

The trusted-device design uses local browser key material to make certain repeat unlocks less cumbersome. Its physical-browser behavior, key persistence, and cleanup require G06 acceptance, and sensitive changes are protected by a recently verified Google sign-in policy where applicable. A server-side device or session revocation can deny future authorization, disable the relevant wrapped key slot, and require a fresh trusted path.

Revocation does not erase a seed copied before the action, force an offline browser to forget every retained byte, or destroy downloaded encrypted backups. If a physical device was stolen, secure the Google account and original websites in addition to using Vault revocation controls. Do not interpret a displayed revoked status as confirmation that no other credential copies exist.

Account recovery is intentionally not an admin reset

If a member forgets the Vault passphrase, a matching saved recovery key may still unwrap the encrypted Vault key after Google authentication. If Google sign-in is lost, a compatible local encrypted backup and its matching key can supply an independent browser-only restore route. Those two scenarios require different prerequisites. The cloud service is not designed to reissue a missing recovery key or decrypt ciphertext merely because someone knows the account email.

Each original website's backup codes are separate from 2FASync recovery material. Losing all copies of the long-lived TOTP seed, encrypted backup, and matching unlock material may leave the original service's own account recovery as the only remaining option. This trade-off is part of respecting private encryption keys rather than retaining a universal service-admin decryption backdoor.

Sync integrity, tampering, and deletion are distinct concerns

Member changes use encrypted records and revisions; a conflict between edits on two devices should be surfaced rather than silently accepting the last write. Deletions are represented with tombstone records so another device can learn what changed while offline. Encrypted payload integrity checks help identify records that have been corrupted or swapped. None of these mechanisms can independently prove the original website still accepts the associated seed.

A user should review a conflict before discarding an older credential, maintain encrypted backups, and verify actual account sign-in after migration. An apparently successful local edit is not identical to a server-confirmed sync acknowledgment. Exact send/receipt semantics and failure interleavings are part of the staging verification program.

What independent release verification must still prove

Source-level checks and test fixtures can establish that code follows a defined contract, but they do not replace a physical browser test, real Google callback roundtrip, approved key-derivation benchmark, migration export from a real authenticator, PostgreSQL runtime, backup/restore exercise, load test, or operational readiness review. Some of these gates remain open in the program. No one should mistake a detailed design document or locally successful build for an authorized production launch or external security certification.

Security findings should be reported with sanitized reproduction steps and without actual OTP seeds or encrypted backup passwords. Before a coordinated disclosure channel is advertised, its destination and operator must be verified. This site cannot responsibly invent an email address, response deadline, audit badge, or security certification to make the page look complete.

Can someone steal authenticator secrets from an unlocked browser?

Yes. Malware or code executing with the page's privileges can undermine client-side secrecy. Encryption of stored or synchronized data does not protect an actively compromised browser.

Is a trusted-device key always hardware-backed?

No. A browser's non-extractable-key property is not equivalent to hardware-backed key storage, and target devices still need G06 physical-browser verification.

Can support reset my Vault and recover all my TOTP secrets?

The encryption design does not include a universal support decryption key. Use a valid Vault recovery key or matching encrypted backup, otherwise pursue the original website's recovery options.