Security architecture

The short version

Keythentic encrypts your vault on your device, using a key derived from your master password, before anything is written to storage or backed up anywhere. We designed it this way so that Keythentic itself — including our own team — never has the ability to read your vault, whether or not you ever back it up.

Client-side, end-to-end encryption

Your master password never leaves your device. It's run through a modern, memory-hard password-hashing algorithm (Argon2id) to derive an encryption key, which in turn protects your vault contents — TOTP secrets, saved logins, cards, secure notes, and passkeys — using AES-256-GCM authenticated encryption. All of this happens locally, on your phone.

We're deliberately not publishing exact parameters (iteration counts, memory costs, and similar low-level specifics) on this public page, both because they may change between versions and because that level of detail belongs in a technical security write-up rather than a marketing site. The architecture itself — client-side key derivation, authenticated symmetric encryption, no server-side key custody — is what matters for understanding what we can and can't access.

No server-side key custody

Keythentic does not operate an account or sync server today. There is nothing to breach on our end that would expose your vault, because your vault and your master password never reach any server we run in the first place.

Backups stay encrypted

If you back up to your own Google Drive, the file uploaded is your already-encrypted vault — the same encrypted blob that lives on your device, uploaded as-is to a private, app-specific area of your own Drive that isn't visible in your regular Drive file list. Keythentic's team has no access to your Google Drive or to that file. The same is true of local encrypted export: the file you save is encrypted before it touches your device's storage.

Biometric unlock uses your device's hardware, not ours

Fingerprint and face unlock are handled entirely by Android's own biometric APIs and the Android Keystore. Your biometric data is processed and stored by your device's secure hardware — it is never sent to Keythentic, and we never see it.

Acting as an Autofill and passkey provider

When you enable Keythentic as your Android Autofill service or as a Credential Manager (passkey) provider, Android grants it the ability to read the on-screen fields of the app or site you're filling into (so it can offer or save a matching credential) and to respond to passkey requests on your behalf. This is the same model every password manager and passkey provider on Android uses, it's controlled entirely by you through Android's own Settings, and it doesn't change how your vault itself is encrypted or stored.

What leaves your device

This is the complete list. Keythentic has no analytics, no crash reporting and no telemetry of any kind, and no build of this app reports to us that you opened it except through the one switch below that says, in those words, that it does — and that switch is off until you turn it on. The one thing that does learn you opened the app is Google Play, when the app asks it whether an update exists; that is the last entry below. Every entry names what starts it and how often.

• Your encrypted vault, to your own Google Drive. Only when you tap “Back up to Google Drive now”, or on an interval you pick if you turn automatic backup on — it is off until you do. What uploads is the already-encrypted vault file, into a private app-specific folder in your Drive rather than your visible files. It is never decrypted to be uploaded, so we could not read it even if we had it.
• Five characters, to check a password against known breaches. Only when you tap “Check password for data breaches”. The app sends the first five hexadecimal characters of that password's SHA-1 hash and compares the rest on your phone, so the service never sees the password, never sees the full hash, and never learns whether you were affected.
• A relay connection, when you sign in on a computer with a passkey. Scanning the computer's QR code opens an end-to-end encrypted tunnel through the relay that QR code names — Google's or Apple's, chosen by the browser, not by us. The relay only passes encrypted bytes between the two devices; your passkey's private key never leaves your phone. Your phone also broadcasts a short encrypted Bluetooth signal for the length of that sign-in, so the computer can confirm you are nearby; it carries nothing but a random value that only that computer can read.
• A logo request, when you add an account. Off until you switch it on. With it on, the app asks keythentic.com — served through our CDN, Cloudflare — for that service's logo, so our server can see which of those brands you use. It can only ever be one of the brands on the list described in the next point — the one the app ships with, plus the one it downloads: your phone matches what you typed against that list locally and can only ask for a name the list already contains, so what you typed as the account name never leaves your phone, and an account we have no logo for sends nothing at all. Never your usernames, passwords or codes. A logo we have is downloaded once and then kept on your device; a service we have no logo for is re-checked about once a month, in case we have added one. We keep no request log for that endpoint.
• The brand catalogue itself, at most once a week. That catalogue used to be fixed and built into the app, which meant a logo we added only reached you when you installed a new version of Keythentic. It is now a small file your phone downloads from keythentic.com — once when you first switch logos on, then at most once every seven days — and it is covered by the same switch: turn logos off and this stops too, and a phone that has never had logos on has never asked for it at all. What our server can see is that someone at your IP address is running a build of Keythentic with that switch on, about once a week. The request carries no account, no device or install identifier, no cookie, and nothing from your vault. It does not even say which version you are running, or which catalogue you already have, so everyone who asks gets the same file. The app also keeps the list it shipped with, and adds the downloaded one to it rather than replacing it — which is why logos still work on a phone that has never been online, and why a failed or truncated download can never leave you with fewer brands than the app came with. The same arrangement has a limit worth naming: a brand we remove from the published list goes on being asked about by copies of the app that already had it, until those are updated. We are not claiming more than that: nothing signs this file beyond the HTTPS connection it arrives over. What your phone does instead is check its shape — every name in it has to be a plain lowercase-letters-and-digits brand name, within fixed limits on how long each may be and how many there may be — and if any part of the file breaks those rules your phone discards the whole of it and keeps using the list it already had. That check is worth what it says and no more. It means a malformed or truncated file can make logos go stale, but cannot make your phone request some strange address or run it out of memory. It does not prove the file came from us. Anyone able to serve that file in our place could fill it with brand names we never chose — including names picked to find out whether you use one particular service — and your phone would go on to ask about whichever of them matched something you had typed. That is the honest residual risk of a file nobody signs, and it is why we publish it in the open, byte for byte as your phone receives it: keythentic.com/icons/v1/catalogue.json.
• A check for an in-app announcement, at most once a day. Off until you switch on “Product announcements”. With it on, the app asks keythentic.com — again through our CDN, Cloudflare — whether we have an announcement to show, at most once every 24 hours rather than every time you open the app. The request carries no account, no device or install identifier, no cookie, and nothing from your vault. It does not even say which version you are running: everyone who asks gets the same file, and your phone picks the entry that applies to it. So what our server can see is that someone at your IP address is running a build of Keythentic with this switch on, roughly once a day — not who you are, and never what is in your vault. What comes back is plain text: it can only ever link to keythentic.com, the button that opens such a link is labelled with that domain and cannot be given any other wording, and there is nowhere in it to type anything, so an announcement can never ask you for your master password. We keep no request log for that endpoint.
• An update check, to Google Play. Asks whether a newer version of Keythentic exists, sending your device and app version. It runs when you open the app — once a day, or about an hour later if a check could not reach Play — and whenever you tap “Check for updates”. Nothing from your vault is involved.

Everything else — generating your codes, deriving your key, unlocking, autofill matching, and creating and using passkeys on this phone — happens entirely on your phone, with no network access at all.

Open about what we haven't done yet

Keythentic is an early-stage product built by a small team. We have not yet commissioned a formal third-party security audit — that's on the roadmap as the product matures, and we'll update this page when it happens. We'd rather tell you honestly where things stand than overstate our security posture.

Questions about this architecture? Get in touch — we're happy to talk through it.