Written as if our own server were hostile

• Your accounts are encrypted with AES-256-GCM under a random data key. What is written to disk is a sealed envelope, kept free of anything that identifies you or your accounts.
• The data key is never stored in the clear. It is wrapped either by a key the browser holds for this installation and will not hand out, or by a key made from your master password with PBKDF2-SHA256 at 600,000 rounds.
• A recovery key of 160 random bits wraps the same data key a second time, so it still works after you change your password.
• The extension asks for no host permissions. Reading a QR code from a page and filling in a code both run under activeTab, which the browser grants only for the tab you opened the extension on. A web page cannot drive the vault.
• Nothing is fetched to show a service's logo: the artwork ships inside the extension.

• Everything is encrypted on your device before it is uploaded. The server stores ciphertext, and only the little it needs to put changes in order: record ids, revision numbers, timestamps, and whether a record was deleted.
• Your account password is stretched on your device and split into two unrelated keys. One wraps the data key and never leaves the device. The other proves the password to the server, which never receives the password itself.
• Your devices refuse weak key-derivation settings from the server, so a server cannot make your password cheaper to attack.
• Each record is bound to its id and revision. A server that moves a record under another id, or replays an old revision as a new one, produces something that will not open — and a record that will not open is skipped and reported, never trusted.
• A deletion carries nothing to check, so deletions are always reported, and what was deleted stays restorable on your device.
• The recovery key's state is sealed under the data key, and a device never goes back to an older one: a retired recovery sheet cannot be brought back to life.
• Changing the account password or the recovery key, and deleting the account, all need the account password. A signed-in session alone is not enough.
• A server restored from a backup says so, and your devices send back what it lost. Saying so falsely gains a server nothing: a device never swaps its copy for an older one.

Encryption hides what is in your vault, not that you have an account. Whoever runs the sync server — today, that is us — can see your email address, the addresses and times you connect from, how many items your vault holds and when each changed, and how many devices you use and what they are called.

They cannot see issuers, account names, secrets, notes or pictures.

• Without a master password, the key is kept by the browser. That does not protect against malware running as you on the same computer, and the extension's settings say so.
• A device that has never seen any recovery-key state accepts the first genuine one it is given. A server cannot forge one, but could hand a newly joined device an older one it kept.
• The extension's code is public; the sync server's is not. That is why the extension is written so that the server need not be trusted.

Every claim above is about the extension's own code, which you can read: Keyrook Authenticator is open source under GPL-3.0. One of its tests, packages/core/test/hostile-server.test.ts, plays a server that tries each of the attacks under “When sync is on”.

Read the source on GitHub

Found a way to weaken any of this — in Keyrook Authenticator, its sync server at api.keyrook.com, or this site? Write to hello@keyrook.com with “Security” in the subject line, rather than opening a public issue. Please include:

• what an attacker could do, and what they would need first;
• the version you tested (Settings → About) and your browser;
• steps, or a proof of concept that shows it.

We will reply to confirm we have it, keep you told as we work on a fix, and credit you in the release notes if you would like that.

Write a security report security.txt