Your TOTP Seeds Belong With the Account, Not in a Screenshot

Enrolling in two-factor authentication is a five-second decision that creates a permanent storage problem, and almost nobody plans for it. The enrollment screen shows a QR code, you scan it with your phone, and you move on. Do that across a handful of accounts and the phone is a perfectly good answer. Do it across sixty accounts belonging to twenty separate identities and the phone becomes a single flat list whose labels no longer tell you which identity each entry belongs to.

The labels are the first thing to go. An authenticator app names entries after the service and the account, which is exactly the information you were trying to keep apart. Twenty entries reading the same service name with twenty usernames underneath is a directory of your compartments, sitting in one app, on one device, sorted alphabetically for convenience.

So people screenshot the QR code, just in case. That screenshot is the seed, in plaintext, sitting in a photo library that syncs to a cloud account — which is very often protected by the same second factor the screenshot is a backup for. It is a circular dependency wrapped around a plaintext secret, and it usually lives in the same place as the passwords, which undoes the entire point of having a second factor.

What makes this specifically bad, rather than merely untidy, is that a TOTP seed is not like a password. A password is one credential for one account, and it can be rotated in a few seconds by someone who is already signed in. A seed is a key that generates every future code for that account until someone re-enrolls, and re-enrolling requires already being able to log in. Losing the seed and leaking the seed are both close to unrecoverable, in opposite directions, and the screenshot folder manages to expose you to both at once.

The recovery codes have the same shape and get treated even more carelessly, usually as a text file named something like codes.txt. They are single-use passwords that bypass the second factor entirely, which makes them the most valuable thing in the whole arrangement and the least likely to be stored as if they were.

Persona Kit's answer is to stop treating credentials as a separate filing system from the identity that owns them. The accounts a persona creates live on that persona: the site, the username, the password, and the TOTP seed, stored together. Passwords and seeds are encrypted with AES-256-GCM under a dedicated key, and neither travels with an ordinary list request — you can see that a persona has an account at a site, and work with that fact, without the secret being handed out merely to render a row.

That last detail is a small design decision with a large effect. Most credential interfaces fetch the secret to display the row and then hide it behind a toggle in the browser, which means the secret has already crossed the network and is sitting in memory on the client whether or not anyone clicked anything. Fetching it only when it is actually asked for turns a constant exposure into an occasional, deliberate one.

When you need to sign in, you pull a current six-digit code on demand rather than reading the seed out and pasting it somewhere. That difference matters more than it looks. The seed stays where it is, and the thing that crosses the wire is a value that expires in thirty seconds and is useless to anyone who captures it afterwards.

Reveals are recorded. Every time a password is shown, it is written to that persona's activity trail alongside everything else that has happened to it. On a shared workspace this is the difference between knowing that somebody on the team has a credential and knowing who took it and when — which is the difference between an incident you can scope and an incident you can only guess at. On a solo account it is still useful, because an unexplained reveal in the trail is a signal you would otherwise have no way to see at all.

The scoping is worth setting up properly if you use the API. Vault access is a separate scope from everything else, so a key that manages personas and launches browser sessions does not have to be a key that can read credentials — and for the overwhelming majority of automation, it should not be. Automation typically needs to know that an account exists, not what its password is. Keys are stored as hashes and shown once on creation, so the copy you hold is the only copy, and a key that turns out to be too broad is revoked and reissued rather than quietly tolerated.

None of this removes the need to think about the phone. A hardware key or an authenticator app is still the right answer for the accounts that are actually yours — your email, your bank, the account that owns the domain. The argument here is about the other sixty: the ones that belong to identities rather than to you, where the seed's job is to be retrievable by the right person months from now, and where a folder of screenshots is the thing standing between you and that.