KeyGuard Password is now KeyCare Pass. Same vault, same account, a new name and address.

Security whitepaper

How KeyCare Pass keeps your secrets

The design behind KeyCare Pass's encryption, authentication and sharing, written for security reviewers and curious users.

Version of October 2026. Describes KeyCare Pass as it runs at vault.keycarepass.com and on self-hosted servers.

Summary

KeyCare Pass encrypts vault data on the user's device. The server stores and synchronizes encrypted data and never receives the master password or the keys derived from it. Sharing between people uses public-key cryptography, so an organization's key reaches a member only after an owner or admin confirms them.

KeyCare Pass is open source: the apps under GPL-3.0 and the server under AGPL-3.0. Anyone can check that this document describes what the code does.

Keys and how they are made

Master key

When you sign up or sign in, your device derives a 256-bit master key from your master password, with your email address as the salt, using one of two key derivation functions:

  • PBKDF2-SHA256, 600,000 iterations by default (you can choose 600,000 to 2,000,000).
  • Argon2id, by default 6 iterations, 32 MiB of memory and a parallelism of 4 (you can choose 2 to 10 iterations, 16 to 1,024 MiB and a parallelism of 1 to 16).

The master key never leaves your device. HKDF-SHA256 expands it into two keys, one for encryption and one for authentication.

Account encryption key

Each account has a random 512-bit account encryption key: 256 bits for AES-256 and 256 bits for HMAC-SHA256. The keys derived from your master key encrypt it, and the server stores only that encrypted copy. Because of this extra layer, changing your master password re-encrypts one key rather than your whole vault; rotating the account key re-encrypts the vault.

Key pair

Each account also has an RSA-2048 key pair. The public key is stored as it is, so others can encrypt keys for you; the private key is encrypted with your account key. The key pair is what makes sharing, emergency access and account recovery possible.

Encrypting vault data

Every field of every item, including its name, is encrypted with AES-256 in CBC mode with a random initialization vector, and authenticated with HMAC-SHA256 so tampering is detected before anything is decrypted. Items you own are encrypted with your account key; items in an organization's collections with the organization's key.

Attachments

Each file gets its own key, which is encrypted with the item's owner key. The file is encrypted on your device and uploaded already encrypted.

Send

A Send is encrypted with a key derived from a random 128-bit secret. The secret is part of the link, after the # sign, which browsers do not send to servers. Anyone with the full link can decrypt the Send; the server alone cannot. An optional Send password is checked by the server before it hands over the encrypted Send.

Signing in

To prove you know your master password without sending it, your device computes a master password hash: one more PBKDF2-SHA256 round over the master key, with the master password as the salt. The server hashes that value again with PBKDF2 (100,000 iterations) before storing or comparing it, so a copy of the database does not contain anything a client could send.

Two-step login

Accounts can add authenticator apps (TOTP), FIDO2 WebAuthn security keys and passkeys, codes by email, or Duo. A recovery code turns two-step login off if you lose your second factor. Enterprise organizations can require two-step login for their members.

Log in with a passkey

The web vault can sign in with a passkey instead of your email and master password. Where the browser supports the WebAuthn PRF extension, the passkey can also unlock the vault.

New devices and sign-in activity

Accounts without two-step login confirm a sign-in from a new device with a code sent by email. Every account can see its sign-ins from the last 90 days, and we email you when your account signs in from an IP address it has not used lately.

Sharing in organizations

An organization has its own symmetric key. When an owner or admin confirms a member who has accepted an invitation, their device encrypts the organization key with that member's RSA public key (RSA-OAEP). The member's device decrypts it with their private key.

Before confirming, both sides can compare the member's fingerprint phrase: words derived from their public key. If the phrases match, nobody has swapped in another key. Collection permissions decide which items each member's apps can show and change; members of an organization never receive another member's account key.

Emergency access and account recovery

Emergency access lets you name a trusted person. Your device encrypts your account key with their public key, and the server releases it to them only if they request access and you do not reject the request before your waiting period ends.

Account recovery, an Enterprise policy, works the same way with the organization's key pair: when a member enrols, their account key is encrypted with the organization's public key. An owner or admin can then set a new master password for that member, which the member must change at their next sign-in. Recovery never shows the old master password and does not turn off the member's two-step login.

Checking for exposed passwords

The exposed passwords report and our breached password checker use k-anonymity. The browser hashes the password with SHA-1 and sends only the first five hexadecimal characters of the hash to the Pwned Passwords service, which returns every hash suffix that starts with them. The browser looks for a match locally. Neither the password nor its full hash leaves the device.

Hosting and transport

The KeyCare Pass service at vault.keycarepass.com runs on servers that GovPAM operates in the European Union, in containers with a PostgreSQL database. All traffic uses TLS. Account emails go through Cloudflare Email Service; payments go through PayFast, which keeps card details and gives KeyCare Pass a token.

Organizations can run the same server themselves on a Docker host, behind their own reverse proxy, with their own database, files and backups.

What GovPAM can and cannot do

GovPAM cannot read vault data, recover a forgotten master password or turn off someone's two-step login without their recovery code. GovPAM can see account metadata: email addresses, devices, sign-in times and IP addresses, organization memberships and policies, and event logs. Like any provider of web-delivered software, GovPAM serves the code your browser runs; publishing the source and its releases lets others check it.

Reporting a vulnerability

Email [email protected]. See responsible disclosure for what to include.