An honest assessment of what Keygrain protects against, what it does not, and the trust boundaries involved.
No password database exists. Passwords are derived on-demand from inputs and discarded after use. There is nothing to exfiltrate from a server.
Derivation uses Argon2id (64 MiB memory, 3 iterations) making each guess take ~1 second on consumer hardware. An attacker who knows the algorithm, your email, and a target site still faces this cost per attempt.
However: Argon2id slows attacks but does not make a weak passphrase safe. A 4-word passphrase (~50 bits of entropy) is within reach of a determined attacker with GPU clusters. Use a strong, high-entropy secret.
Site configurations are encrypted client-side with AES-GCM using a key derived from your master secret via Argon2id. The sync server receives only ciphertext. It cannot read service names, emails, or configuration.
If your secret is exposed (phishing, keylogger, shoulder surfing), all passwords are compromised. This is the single point of failure inherent to deterministic password managers. Mitigation: use Keygrain only on trusted devices.
If malware has access to your device's memory or input, it can capture your secret as you type it. Keygrain cannot protect against a compromised operating environment.
Keygrain does not monitor whether your generated passwords have appeared in data breaches. If a site is breached, you must manually rotate by incrementing the counter for that site.
If one generated password is leaked (e.g., a site stores it in plaintext), an attacker could attempt to reverse-engineer your secret. Argon2id makes this expensive but not impossible for weak secrets.
Sync uses last-writer-wins by timestamp. If two devices have skewed clocks, the device with the "later" timestamp wins regardless of which edit was actually more recent. Mitigation: keep device clocks synchronized (NTP).
The sync model uses absence = deletion. If device A deletes a service and pushes after device B edited it, the deletion wins. The edit is lost. Mitigation: avoid concurrent edits across devices for the same service.
A malicious sync server could serve stale (old) encrypted payloads on GET requests, causing a device to revert to an older configuration. The server cannot forge new content (it lacks the encryption key), but it can replay old valid ciphertext.
The sync server can observe: number of services stored, timestamps of sync operations, and payload size. It cannot observe service names, emails, or password configurations (these are encrypted).
| Boundary | Trust Level | Rationale |
|---|---|---|
| Local device | Fully trusted | Secret is entered and derivation happens here. If compromised, all security is lost. |
| Sync server | Untrusted for content | Sees only ciphertext. Trusted for availability and ordering (replay risk noted above). |
| Browser extension | Scoped trust | Requests tabs permission for active tab detection. Code only reads the current active tab URL — does not access other tabs or history. |
| Web generator | Fully local | Runs entirely in-browser. No network requests. Can be used offline. |