Encrypted sync moves Vault records, not ready-made verification codes

Google authentication answers who owns the Vault

The member logs in through Google OpenID Connect so the server can identify an authorized account and bound session. It may then return encrypted Vault envelopes, key slots, device information, and version records. That identity step does not disclose the Data Encryption Key or make Google the key holder. The browser must use a separately supplied Vault passphrase, matching recovery key, or approved local device key path to unwrap the encryption material.

Separating these responsibilities prevents a normal server query from needing the TOTP seed to render a list or calculate a code. It also means support cannot simply reset an unknown decryption key because somebody can prove their email address. A lost passphrase may still be recoverable with previously saved recovery material; losing every unlock route may make ciphertext permanently unusable.

Encrypt the secret-bearing entry before synchronization

Each authenticator entry includes data such as issuer, account label, Base32 seed, algorithm, code length, favorite status, and notes. The member Vault encrypts the item inside the browser with a per-vault key using authenticated encryption. Versioned envelopes and integrity checks help detect tampering or a ciphertext record placed in the wrong context. Under the intended normal flow, the server persists encrypted item records rather than calculating TOTP numbers from plaintext account secrets.

The server still sees necessary metadata: authenticated identity, opaque item and device identifiers, encrypted lengths, revisions, timing, and bounded security events. Neither the term encrypted nor end-to-end encrypted should be interpreted as zero information leaving the browser. Production controls, logging configuration, malicious scripts, and actual browser behavior require separate testing.

A second device downloads ciphertext and unlocks locally

After signing into the same member identity and satisfying device authorization, another browser pulls the latest encrypted records and matching key-slot metadata. It can then derive or obtain the local unwrap key from the member's passphrase or recovery material and decrypt the entries in its own browser context. TOTP generation continues locally once a supported entry is available. Sync does not require sending each current one-time number to a central code-generating API.

A device may be offline, unregistered, revoked, or missing an approved local key profile, and those states can interrupt the flow. The mere presence of ciphertext in a database is not a promise that every browser can decrypt it immediately. Keep tested backup and recovery material independently of daily synchronization.

Revision checks preserve disagreement instead of hiding it

Two devices can change the same authenticator item before they have exchanged revisions. A safe revision-aware system identifies conflicts and preserves the relevant encrypted versions for reconciliation after local decryption. Deleting an item produces a tombstone to inform a device that was offline about the earlier removal. It should not automatically resurrect stale records when that device later reconnects.

Treat a sync conflict as a request to compare your deliberate edits and the original service's current enrollment. Do not guess which seed should win simply from the latest timestamp or assume an apparently completed request has been committed without an authenticated acknowledgment. The application's journal and synchronization receipts address this uncertainty, but their physical failure and race behavior still require the designated staging gates.

Understand the threat model before trusting the cloud

Encryption at rest and in transit can limit exposure from some server or database incidents, but it cannot protect a Vault after malware or hostile code gains full control of an unlocked browser. Copying an OTP to the system clipboard can also expose a short-lived value to local software. An exported QR or decrypted backup voluntarily shared elsewhere falls outside the encrypted sync boundary. Lock the Vault when idle and restrict extensions on high-risk accounts.

Device-revocation controls can deny future server-authorized use of a revoked path but cannot erase all data someone previously saved. Browser-protected keys are not automatically hardware-backed or immune to compromise. G04 key-derivation benchmarks, G06 real-device evidence, and the remaining runtime acceptance gates are required before this implementation design can be called fully proven for public production.

Can 2FASync's server calculate my Vault's TOTP codes?

In the normal intended member flow, it handles encrypted records and session metadata while the unlocked browser decrypts the entry and calculates its TOTP. This is a design boundary, not a promise against compromised client code or every operational failure.

Does Google sign-in replace my encryption passphrase?

No. Google sign-in establishes account identity. Vault encryption uses independently managed unlock material.