Every authenticator app says it protects your codes. Most of them mean the codes are encrypted somewhere between your phone and a server. That is a real thing, and it is not the same thing as the server being unable to read them.
KeyNesta is built so that we cannot read your codes. Not "will not" as a policy we could change, or a promise in a privacy page. We cannot, because the keys never exist on our side. That property has a cost, and we would rather explain the cost up front than have you discover it on a bad day.
The mechanism
Your vault is encrypted on your device with AES-256-GCM. The key for that encryption is derived from your passphrase using scrypt, which is deliberately slow and memory-hungry, so that guessing passphrases in bulk is expensive rather than cheap.
What leaves your device is ciphertext plus the minimum a sync needs in order to work at all: which object changed, and when. Our server stores that ciphertext. It has no copy of your passphrase, no copy of the derived key, and no way to produce either.
That is the whole claim. It is not complicated, and its simplicity is the point: the smaller the set of things we hold, the smaller the set of things anyone can take from us.
What that buys you
If our server is breached, the attacker gets a pile of ciphertext they cannot open. If we are compelled to hand over data, we hand over that same pile. If an employee goes looking through the database out of curiosity, there is nothing legible to find.
Compare that with a design where the provider holds the decryption key. Every one of those scenarios ends differently, and none of the differences are in your favour.
What it costs
Here is the part most marketing pages leave out.
We cannot reset a forgotten passphrase. There is no recovery email, no support ticket, no identity check that ends with us letting you back in. We do not have the key. If you forget your passphrase and have no backup, the vault is gone. Not locked pending review. Gone.
That is not a gap we intend to close. Any mechanism that would let us restore your vault would, by construction, be a mechanism that lets us read it. A recovery path we control is a key we hold. You cannot have both properties at once, and we picked the one that survives a breach.
So the honest summary is a trade:
- We cannot lose your codes to an attacker who takes our database.
- You can lose your codes to a forgotten passphrase.
The second risk is one you can manage. The first is not, if the provider made the other choice.
What to do about it
Keep a backup. Write the passphrase down and put it somewhere you would keep a passport. A sealed envelope in a drawer is a better recovery mechanism than a support inbox, because it is one you control and nobody else can be tricked into using.
Export your vault occasionally. KeyNesta imports from Google Authenticator, Aegis and 2FAS, and exports in a form other apps can read, because an authenticator that traps your codes has made itself a different kind of single point of failure. The import and export guides cover both directions.
And if you are choosing between authenticators, the question worth asking is not whether the app is encrypted. Almost all of them are, in some sense. The question is whether the company can read your codes if it decides to, or is asked to, or is breached. That answer is architectural, and it is the one we designed around.
The same question applies one layer up. If your 2FA codes live in your password manager, whoever can open that vault holds both factors at once. Sometimes that is a fine trade and sometimes it is not; should your 2FA codes live in your password manager? argues it both ways.