AES-256-GCM with random IVs
Every secret is sealed with a random initialisation vector and its own random salt. Tampering is detected at decryption time rather than silently passed through.
Security
How Teampass protects your secrets
The encryption model, the key distribution model, what the threat model covers — and, just as importantly, what it does not.
We publish every advisory we fix — nine were closed in 3.2.1.1 alone. A password manager that reports no vulnerabilities is not a password manager that has none; it is one nobody is looking at, or one that is not telling you.
Authenticated AES-256-GCM
Rebuilt in the 3.2.1 line. The previous format used AES-CBC, which encrypts but does not authenticate — a tampered ciphertext would decrypt to garbage rather than being rejected.
PBKDF2 at 600,000 iterations
Raised from 1,000, in line with current NIST guidance, with HKDF-SHA256 added for key derivation.
256-bit object keys
Per-secret key entropy went from 64 bits to 256 bits, while remaining backward compatible with existing data.
Lazy migration
Existing secrets re-encrypt into the new format on first read, with progress tracking. No maintenance window, no bulk migration script to babysit.
After an upgrade, the hardened format is off by default. New installations enable it automatically; upgrades leave it disabled so an upgrade never changes behaviour underneath your users. Turning it on is a deliberate step — and one worth taking.
Why revoking access actually revokes it
Teampass does not hold one master key that decrypts everything. Each item has its own object key, and that key is wrapped separately for every user entitled to it — a sharekey. Granting access means creating a sharekey; revoking access means destroying one. There is no ambient ability to read an item that your rights do not cover.
Personal folders are genuinely personal
Since 3.2.1.1, only the owner and the designated recovery account hold keys to a personal folder. An administrator can manage the instance, reset accounts and run the server, and still cannot read what is in your personal folder. Treat the recovery account accordingly: it is the one remaining path in.
A sharekey is not an access grant
3.2.1.3 tightened this boundary explicitly. Holding key material is not by itself authorisation — every read is still checked against the folder and role model. The two are enforced separately on purpose, so a bug in one does not quietly become a bypass of the other.
Resilient distribution
When keys are redistributed across many users, a single failing account now isolates itself instead of aborting the batch. RSA operations moved into background tasks, so saving an item stays fast in large installations.
Getting in
Two-factor authentication
RFC 6238 TOTP with configurable profiles — algorithm, digit count and period — so Teampass fits an existing MFA standard rather than imposing its own.
Single sign-on
OAuth2 against your identity provider, or LDAP and Active Directory with nested group resolution in both login modes.
Lockout management
Brute-force protection with administrator visibility and control over lockouts, added in 3.2.1.3.
Scoped privilege
Role assignment is validated against the caller's own roles: an administrator cannot grant rights they do not themselves hold.
What this does and does not protect you from
Any vendor that answers "everything" is selling you something. Here is the honest boundary.
Protects against
- Database theft — secrets are useless without the key material
- Over-broad internal access — rights are enforced per folder and per item
- Silent tampering with stored ciphertext
- Credentials lingering after someone leaves, once the account is disabled
- Unaccountable access — every read is recorded
Does not protect against
- A compromised server — root on the host can observe secrets in use
- A compromised workstation — a keylogger sees what the user sees
- A user who is entitled to a credential and then leaks it
- Weak deployment — no TLS, no backups, a public instance with a weak admin password
- A lost recovery account combined with a lost owner passphrase
How vulnerabilities are handled
Report vulnerabilities through the security policy, not the public issue tracker. Fixes are shipped in a release and published as a GitHub Security Advisory with an identifier, an affected version range and a description of the defect.
That record is deliberately public. Nine advisories were published with 3.2.1.1, two more with 3.2.1.2, four with 3.2.0.8 — including authentication bypasses and a privilege escalation. Publishing them is uncomfortable and it is the correct behaviour: you cannot assess the risk of software whose defect history is hidden from you.
Deployment hardening checklist
The cryptography above assumes a competently deployed server. These are yours to get right.
Terminate TLS properly
Valid certificate, modern ciphers, HSTS. Never expose the instance over plain HTTP.
Limit exposure
Restrict to the networks that need it. A credential vault rarely needs to face the open internet.
Delete the install directory
Once setup is done, remove it. Verify file permissions on the configuration.
Back up, and test restoring
An untested backup of an encrypted database is a guess, not a recovery plan.
Keep background tasks running
Key distribution, posture scans and rotation tracking depend on the scheduler.
Upgrade promptly
Advisories are published with each release. Watch the repository and apply security releases quickly.
Read the code, not the datasheet.
The full source is public under GPL-3.0. Your security team can verify every claim on this page.