Product Security 
Most password managers on the market require only the user's master password to access their password vault. If the master password is compromised, a cybercriminal could
Keeper Security’s zero-trust and zero-knowledge encryption model ensures that even in a worst case scenario, all of the contents of your Keeper vault would be protected with multiple layers of safeguards and encryption. Keeper has stood by its commitment to protect your most valuable data for more than a decade, through our best-in-class security model and transparent approach to sharing it with the public.
There are many differentiators between how Keeper protects customer information compared to our competitors. The LastPass data breaches have brought into question how the stored vault information is protected in the case of a data breach. While Keeper takes extensive security safeguards to prevent breaches, customers rightly want to understand our protections, in the event that a breach does occur. A highly detailed document describing the Keeper encryption model is available on this page. This blog post will outline the key protections that would protect users in the event of a data breach.
Encryption of Vault Data
Keeper is built with a multi-layered encryption system based on client-generated encryption keys. 256-bit AES record-level keys and folder-level keys are generated on the client device which encrypt each stored Vault record. All contents of the vault are encrypted, including logins, file attachments, TOTP codes, payment information, URLs and custom fields.
Encryption keys are generated locally on the device to preserve zero knowledge and support advanced features such as record and folder sharing. Zero knowledge means each user has complete control over the encryption and decryption of all personal information in their Keeper vault, and none of their stored information is accessible by anyone else, not even Keeper employees.
Record keys and folder keys are wrapped by another key, which is the 256-bit AES Data Key.
On the user’s device, another 256-bit AES Client Key is generated for encrypting a local offline cache (if your administrator allows offline access). Finally, the 256-bit AES Data Key is encrypted with another key, described in the next section.
Protection of the Data Key
Decrypting a user’s vault requires decryption of the Data Key.
For users who login with a Master Password: The key to decrypt and encrypt the Data Key is derived from the user’s Master Password using the Password-Based Key Derivation Function (PBKDF2), with 1,000,000 iterations. After the user types their Master Password, the key is derived locally and then unwraps the Data Key. After the Data Key is decrypted, it is used to unwrap the individual record keys and folder keys. The Record Key then decrypts each of the stored record contents locally.
For users who login with SSO or passwordless technology: Elliptic Curve cryptography is used to encrypt and decrypt data at the device level. A local ECC-256 (secp256r1) private key is used to decrypt the Data Key. After the Data Key is decrypted, it is used to unwrap the individual record keys and folder keys. The Record Key then decrypts each of the stored record contents. The Encrypted Data Key is transmitted between the user’s devices through a push system or key exchange service we call Device Approval, which is managed by the customer to preserve zero knowledge.
Key Points:
- For customers who use a Master Password to log in, a strong and unique master password is critical, along with the enforcement of 1,000,000 PBKDF2 iterations. By using the Keeper Admin Console, Keeper administrators can easily enforce Master Password complexity rules on end-users and iterations in Keeper’s role-based enforcement policies.
- For customers who deploy Keeper through a Single Sign-On (SSO) product such as Azure, Okta, Ping, ADFS or other identity provider, there is no Master Password to be concerned with, and the threat vector of Master Password key derivation does not exist. In this model, all encryption of data uses Elliptic Curve keys. The protection of data using Keeper SSO Connect is fully documented and patented. A high level overview of the feature is available here.
- A detailed description and mathematical proof of the strength of vaults encrypted with password-derived keys versus Elliptic Curve (EC) keys is described in Keeper’s encryption model documentation. It’s worth noting that the Bitcoin blockchain uses ECC-256. This creates a de facto $300 billion bounty on the strength of 256-bit elliptic curves.
For enterprises looking to deploy a secure password manager to users, Keeper SSO Connect provides the highest levels of data protection in addition to seamless integration with your current identity stack. Since no master password is used, the threat vector of brute force attacks against stored data is eliminated.
Encryption in Transit
Keeper is a SaaS platform that hosts encrypted data in multiple geographic regions with Amazon Web Services (AWS). Customers may host their Keeper tenant in their preferred primary region. Customer data (stored ciphertext) and access to the platform are isolated to the specific region of the customer’s choosing.
All encrypted payloads sent to Keeper servers are wrapped by a 256-bit AES transmission key in addition to Transport Layer Security (TLS), to protect against man-in-the-middle attacks. The transmission key is generated on the client device and transferred to the server using ECIES encryption via the server’s EC public key.
This transmission key encryption provides an additional layer of 256-bit encryption on top of the data encryption already packaged into the payload. The transmission encryption tunnels directly from the user’s device to the application servers in Keeper’s environment.
Cloud Protection
Keeper has created an advanced cloud authentication and network communications model built for the highest levels of privacy, security and trust.
For users who login with a Master Password: A second PBKDF2 key is generated locally with up to 1,000,000 iterations, and then hashed with HMAC_SHA256 to derive an authentication token.
For users who login with SSO or passwordless technology: The user can authenticate through their SSO identity provider and then decrypt the ciphertext of their vault locally on their device. Each device has its own EC (Elliptic Curve) public/private key pair and encrypted data key. To sign into a new device, the user must utilize existing devices to perform an approval or an administrator with the privilege can approve a new device.
In Keeper’s cloud vault (hosted by AWS), we store each user’s vault as encrypted ciphertext, which has been encrypted locally on the user’s device. In addition to the encryption of the payload and encryption of the transmission, Keeper also super-encrypts stored Encrypted Data Keys with hardware security modules in the AWS environment.
Certifications and Compliance
Keeper is the most secure, certified, tested and audited password security platform in the world. Keeper holds the longest standing SOC 2 and ISO 27001 certifications in the industry. Keeper is GDPR compliant, CCPA compliant, FedRAMP authorized, StateRAMP Authorized, and is certified by TrustArc for online privacy. Keeper is PCI DSS certified.
Key Points:
- Keeper does not store secrets such as cloud infrastructure access keys in its source code. We regularly scan source code for secret information.
- Keeper’s source code, while privately held in Github Enterprise, does not provide information required to access a user’s vault. The encryption of data occurs at the local device level, and much of this source code is published in our public Github repository as part of Keeper’s Commander and Secrets Manager products.
- Keeper does not use third party providers such as Twilio for 2FA. Keeper’s vendors have not been subject to any data breaches.
- Keeper does not provide any third parties with management or access to our AWS data centers. All management of infrastructure is performed by full-time employees of Keeper Security who are US citizens, located in the US.
- Keeper has the most security certifications in the industry. Keeper is SOC2 certified, FedRamp Authorized, StateRamp Authorized and ISO27001 certified.
Our Pledge of Transparency
Keeper isn’t just committed to security, we are fanatical about it. That’s why we make every detail of our encryption model available to the public. We believe that our customers deserve to know every step we’re taking to ensure their data is secure in the face of an ever-changing cybersecurity landscape.
Keeper’s zero-trust and zero-knowledge encryption model ensures that even in a worst case scenario, your Keeper vault is protected, and we continually conduct security tests to ensure we remain the best solution to protect your most valuable data.
Keeper performs quarterly application penetration testing of all of our products and systems with 3rd party penetration testers, including NCC Group and Cybertest. These include red-team style penetration tests of both internal and externally-exposed systems with full source code access.
Keeper has also partnered with Bugcrowd to manage its bug bounty and Vulnerability Disclosure Program (VDP). The Keeper Security VDP can be found at bugcrowd.com/keepersecurity.
To increase transparency, Keeper publishes detailed release notes across every platform. If you have any questions, please email security@keepersecurity.com.
