Keeper's Best-In-Class Security
Private Master Password
ONLY the user has knowledge of and access to their Master Password and key that is used to encrypt and decrypt their information.
User data is encrypted and decrypted at the device level not on Keepers servers or in the cloud.
Keeper protects your information with AES 256-bit encryption and PBKDF2, widely accepted as the strongest encryption available.
Secure/Reliable Cloud Vault
Keeper utilizes Amazon AWS in multiple geographic locations to host and operate the Keeper Vault and architecture providing customers with the fastest and safest cloud storage. Data at rest and in transit is fully isolated in a customer's preferred global data center.
Keeper supports multi-factor authentication, biometric login and Keeper DNA which uses personal devices like your smartwatch to confirm your identity.
Keeper Security, Inc. (KSI) is passionate about protecting its customers' information with Keeper mobile and desktop security software. Millions of consumers and businesses trust Keeper to secure and access their passwords and private information.
Keeper's software is constantly improved and updated to provide our customers with the latest in technology and protection. This page provides an overview of Keeper's security architecture, encryption methodologies and hosting environment as of the current published version. An overview into the technical details involving our encryption and security methods are described in this document.
KSI is a Zero-Knowledge security provider. The Keeper user is the only person that has full control over the encryption and decryption of their data. With Keeper, encryption and decryption occurs only on the user's device upon logging into the vault. Each individual record stored in the user's vault is encrypted with a 256-bit AES key that is randomly generated on the device. The record keys are protected by an additional key, called the Data Key. The Data Key is encrypted by a key derived on the device from the user's Master Password. Data stored at rest on the user's device is also encrypted by another key, called the Client Key. Secure record syncing between the user's devices is also encrypted at the network layer and routed through Keeper's Cloud Security Vault. This multi-tiered encryption model provides the most advanced data protection available in the industry.
The encryption key that is needed to decrypt the data always resides with the Keeper user. KSI cannot decrypt the user's stored data. KSI does not have access to a customers' master password nor does KSI have access to the records stored within the Keeper vault. KSI cannot remotely access a customers' device nor can it decrypt the customers' vault. The only information that Keeper Security has access to is a user's email address, device type and subscription plan details (e.g. Keeper Unlimited). If a user's device is lost or stolen, KSI can assist in accessing encrypted backup files to restore the user's vault once the device is replaced.
Information that is stored and accessed in Keeper is only accessible by the customer because it is instantly encrypted and decrypted on-the-fly on the device that is being used - even when using the Keeper Web App. The method of encryption that Keeper uses is a well-known, trusted algorithm called AES (Advanced Encryption Standard) with a 256-bit key length. Per the Committee on National Security Systems publication CNSSP-15, AES with 256-bit key-length is sufficiently secure to encrypt classified data up to TOP SECRET classification for the U.S. Government.
The cipher keys used to encrypt and decrypt customer records are not stored or transmitted to Keeper's Cloud Security Vault. However, to provide syncing abilities between multiple devices, an encrypted version of this cipher key is stored in the Cloud Security Vault and provided to the devices on a user's account upon successful vault login and multi-factor authentication. This encrypted cipher key can only be decrypted on the device for subsequent use as a data cipher key.
Strong Master Password
It is highly recommended that customers choose a strong Master Password for their Keeper account. This Master Password should not be used anywhere outside of Keeper. Users should never share their Master Password with anyone.
To protect against unauthorized access to a customers' account, Keeper also offers Two-Factor Authentication. Two-Factor authentication is an approach to authentication requiring two or more of the three authentication factors: a knowledge factor, a possession factor, and an inherence factor. For more information on Two-Factor Authentication see this link.
Keeper uses something you know (your password) and something you have (the phone in your possession) to provide users extra security in the case where your master password or device is compromised. To do this, we generate TOTPs (Time-based One-Time Passwords).
Keeper generates a 10-byte secret key using a cryptographically secure random number generator. This code is valid for about a minute, and is sent to the user by SMS, Duo Security, RSA SecurID, TOTP application, Google Authenticator or Keeper DNA-compatible wearable devices.
When using the Google Authenticator or TOTP application on your mobile device, the Keeper server internally generates a QR code containing your secret key, and it is never communicated to a third party. Each time a user deactivates, then reactivates Two-Factor Authentication, a new secret key is generated.
To activate Two-Factor Authentication, visit the Keeper DNA or Settings screen of the Keeper Web App. Keeper Business customers can optionally enforce the use of Two-Factor Authentication and supported 2FA methods via the Keeper Admin Console's role enforcement functionality.
FIDO (U2F) Security Keys
Keeper supports FIDO-compatible U2F hardware-based security key devices such as YubiKey as a second factor. Security keys provide a convenient and secure way to perform two-factor authentication without requiring the user to manually enter 6-digit codes. Multiple security keys can be configured for a user's vault. For platforms that do not support security key devices, users may fall back to other configured 2FA methods. To configure a security key and other two-factor authentication methods, visit the 'Settings' screen of the Keeper application.
Emergency Access (Digital Legacy)
Keeper supports the ability to add up to 5 emergency contacts to grant vault access in the event of an emergency or death. Once a specified wait time has elapsed, the emergency contact will gain access to the user's vault. The process of sharing a vault is Zero-Knowledge, and the user's Master Password is never directly shared. RSA encryption is utilized to share a 256-bit AES key with the emergency contact, at the expiration of the wait time set by the originating user. Therefore, the emergency contact must have a Keeper account (and a public/private RSA key pair) to accept the invitation.
Data is encrypted and decrypted on the user's device, not on the Cloud Security Vault. We call this "Client Encryption" because the client (e.g. iPhone, Android Device, Desktop App, etc.) is doing all of the encryption work. The Cloud Security Vault stores a raw binary which is essentially useless to an intruder. Even if the data is captured when it's transmitted between the client device and Cloud Security Vault, it cannot be decrypted or utilized to attack or compromise the user's private data.
Breaking or hacking a symmetric 256-bit key would require 2128 times the computing power of a 128-bit key. In theory, this would take a device that would require 3×1051 years to exhaust the 256-bit key space.
Each user has a 2048-bit RSA key pair that is used for sharing records and messages between users. Shared information is encrypted with the recipient's public key. The recipient decrypts the shared information with their private key. This allows a user to share records only with the intended recipient, since only the recipient is able to decrypt it.
Keeper uses PBKDF2 with HMAC-SHA256 to convert the user's Master Password to a 256-bit encryption key with up to 100,000 rounds. PBKDF2 iterations are based on the device platform and managed by the user in Keeper's 'Advanced Settings' screen.
All secret keys that must be stored (such as each user's RSA private key and the Data Key), are all encrypted prior to storage or transmission. The user's Master Password is required to decrypt any keys. Since Keeper's Cloud Security Vault does NOT have access to the user's Master Password, we cannot decrypt any of your keys or data.
Keeper's Cloud Security Vault
The Cloud Security Vault refers to KSI's proprietary software and network architecture that is physically hosted within Amazon Web Services (AWS) infrastructure.
When the user synchronizes their Keeper vault with other devices on their account, the encrypted binary data is sent over an encrypted SSL tunnel and stored in Keeper's Cloud Security Vault in encrypted format.
Keeper maintains full encrypted version history of every record stored in the user's vault, providing confidence that no critical data is ever lost. From the Keeper client application, users can examine the record history and perform a restore of any individual vault record. If a stored password or file in Keeper is changed or deleted, users always have the ability to perform a point-in-time restore.
Customers who purchase Keeper Business are provided an extra layer of control over their users and devices. Keeper administrators are provided access to a cloud-based administrative console which allows full control over user on-boarding, off-boarding, role-based permissions, delegated administration, teams, Active Directory/LDAP integration, Two-Factor Authentication, Single Sign-On and security enforcement policies. Keeper's role-based enforcement policies are fully customizable and scalable to any sized organization.
Roles, Teams, Shared Folders and Delegated Admin
Keeper for Business provides a secure and robust set of controls over organizational units, roles, teams and shared folders. The powerful back-end controls of Keeper provide the most robust security layers that provide least-privilege access and full delegated administration.
At the encryption layer, every record (e.g. password or credential) stored in the Keeper platform has a unique record identifier (Record UID). Each record is encrypted with a record key. Shared folders have a shared folder key, each team has a team key and a public/private key pair, and every user has a user data key, client key, and public/private key pair. Every role that requires the transferability of the user's account has a role enforcement key and a public/private key pair. Data at rest on the user's device is encrypted with the user's client key. The user's data key and client key are encrypted with the user's Master Password.
Records created by a user have the record key encrypted with the user's data key. Records are added to a shared folder by encrypting the record key with the shared folder key. Records are directly shared to a user by encrypting the record key with the user's public key. Users are added to a shared folder by encrypting the shared folder key with the user's public key. Teams are added to a shared folder by encrypting the shared folder key with the team's public key. Users are added to a team by encrypting the team key with the user's public key.
For Roles that enforce the transferability of a user's account:
The enforcement key is encrypted with each admins' public key that is allowed to perform the transfer.
(Note: separate enforcements applied to separate groups of users may be designated to be transferred by separate groups of admins.)
The user's data key (for users in a role to which the enforcement is applied) is encrypted with the role enforcement's public key.
An account to be transferred is done by locking then transferring and deleting a user's account. This ensures the operation is not performed secretly. The user's shared data key and metadata allow for the eventual ability to decrypt the record data, but do not allow direct access. Thus, only after the records have been assigned to an individual are the records now usable by that individual, and no other individual has gained access.
All encryption is performed client side, and at no time does Keeper have the ability to decrypt the information being shared or transferred. Additionally, at no time is a user's client key shared. A user who is removed from a team, shared folder, or direct share will not receive new data from the team, shared folder, or record. Thus, although the key is compromised with that individual, the key is not usable for gaining access to the underlying data.
Several different administrative privileges may be assigned to portions of a hierarchical tree that allows the members of the privileged role to perform operations in our Keeper Admin Console.
Server-side and client-side enforcement policies may also be applied to roles to dictate the behavior of the client for groups of individuals.
Teams enables easy distribution of shared folders to groups of users.
Keeper Active Directory / LDAP Bridge
The Keeper Bridge integrates with Active Directory and LDAP servers for provisioning and onboarding of users. Keeper Bridge communication is first authorized by an admin with the privilege to manage the bridge. A transmission key is generated and shared with Keeper for all subsequent communication. The use of the transmission key is the authorization for all operations performed by the bridge except for the initialization of the Bridge. The transmission key may be regenerated at any time, and it will automatically rotate every 30 days.
The transmission key is only for transmission which means a compromised key may be reinitialized or revoked without any loss of data or permission.
Keeper Bridge may not give privileges to a role or user. It may add a user to a privileged role, as long as no enforcement keys are needed. Keeper Bridge may not elevate itself or a user above the portion of the tree it is managing. Not all operations are available to the Bridge, i.e. the Bridge can disable an active user, but may not delete the user. The admin will have to choose if the user is to be deleted or transferred.
Single Sign-On (SAML 2.0) Authentication
Keeper can be configured by Keeper Business customers to authenticate a user into their Keeper vault using standard SAML 2.0 identity products. Keeper is a pre-configured service provider in every major SSO Identity Provider such as Google Apps, Microsoft Azure, Okta, Ping Identity and others. The mechanism that Keeper utilizes to authenticate users into their vault in a Zero-knowledge environment is the patent-pending implementation called Keeper SSO Connect™. Keeper SSO Connect is a software application that Keeper Business administrators install on their own infrastructure (either on-premise or cloud), which serves as a SAML 2.0 service provider endpoint. When activated on a particular organizational unit, Keeper SSO Connect manages all of the encryption keys for Keeper Business end-users. Upon successful authentication in to the business Single Sign-On Identity Provider, the user is logged into Keeper with the necessary encryption keys to decrypt their vault. Keeper SSO Connect software operates on Windows, Mac and Linux environments.
KSI utilizes Amazon AWS in North America and Europe, for localized data privacy and geographic segregation to host and operate the Keeper solution and architecture. Utilizing Amazon AWS allows Keeper to seamlessly scale resources on-demand and provide customers with the fastest and safest cloud storage environment. KSI operates both multi-zone and multi-region environments to maximize uptime and provide the fastest response time to customers.
To prevent unauthorized vault access, Keeper's Cloud Security Vault must authenticate each user when transmitting data. Authentication is performed by comparing a PBKDF2-generated hash of the Master Password. The user's device uses PBKDF2 to generate the hash from the Master Password and the server compares the hash to a stored hash.
By using the PBKDF2 hash instead of the Master Password itself, the Cloud Security Vault authenticates the user without requiring the Master Password. PBKDF2 is also used for generating encryption data keys, but the authentication hash is not used for data encryption.
Transport Layer Encryption
KSI supports 256-bit and 128-bit SSL to encrypt all data transport between the client application and KSI's cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns.
KSI deploys SSL/TLS certificates signed by Digicert using the SHA2 algorithm, the most secure signature algorithm currently offered by commercial certificate authorities. SHA2 is significantly more secure than the more widely used SHA1, which could be exploited due to mathematical weakness identified in the algorithm. SHA2 helps protect against the issuance of counterfeit certificates that could be used by an attacker to impersonate a website.
KSI also supports Certificate Transparency (CT), a new initiative by Google to create a publicly auditable record of certificates signed by certificate authorities. CT helps guard against issuance of certificates by unauthorized entities. CT is currently supported in the latest versions of the Chrome web browser. More information about Certificate Transparency can be found at: http://www.certificate-transparency.org/
Keeper's native clients implement HTTP Public Key Pinning (HPKP). HPKP is a security mechanism which allows HTTPS websites to resist impersonation by attackers using fraudulent certificates.
iOS Keychain, Touch ID® and Face ID®
Touch ID on iOS devices allows you to access your Keeper vault on your iOS device using your fingerprint. To provide this convenient feature, an unintelligible version of your Master Password is stored in the iOS Keychain. The iOS Keychain item created for this functionality is not designated to synchronize to the iCloud Keychain and thus will not leave your iOS mobile device.
It is highly recommended that you use a complex Master Password and enable Multi-factor authentication in order to provide maximum security for your encrypted Keeper Vault. Using Touch ID makes it more convenient to use a complex Master Password on your iOS mobile device. It is also recommended that you set a passcode longer than the minimum 4-digits to secure the iOS Keychain.
The iOS Keychain is used by iOS and apps to securely store credentials. iOS apps use the iOS Keychain to store a variety of sensitive information, including website passwords, keys, credit card numbers and Apple Pay™ information. Keeper does not use the iOS Keychain to store your Keeper records - all Keeper records are protected with 256-bit AES encryption and are securely stored in the Keeper Vault. The iOS Keychain is also encrypted with 256-bit AES encryption using the device's passcode. Even if the device is lost or stolen or an attacker obtains physical access to the mobile device, they will be unable to access any stored Keeper information. The iOS Keychain cannot be decrypted without the passcode and the Keeper Vault cannot be decrypted without the user's Keeper Master Password.
The Apple Watch Favorite feature allows the viewing of selected records on a paired Apple Watch. Keeper records must be explicitly enabled to allow viewing on the Apple Watch. A paired Apple Watch communicates with the Keeper Watch Extension that transparently runs in a sandboxed space separate from the iOS Keeper App. The Keeper Watch Extension also uses iOS Keychain to securely store and access keys to enable it to seamlessly and securely communicate with the iOS Keeper app.
Keeper DNA is a new and innovative addition to multi-factor authentication. When used with a paired Apple Watch, Keeper DNA provides a multi-factor authentication method that is unparalleled in convenience and security. Keeper DNA uses secure tokens stored in the Keeper Vault to generate time-based codes for multi-factor authentication. These time-based authentication requests can be approved and sent automatically from the Apple Watch with a tap on the screen of the watch or entered manually by the user. Multiple layers of encryption, Touch ID and multi-factor authentication help make Keeper DNA the most elegant, secure and advanced authentication method available.
Security Audits, Scanning & Testing
Third-Party Security Scanning & Penetration Tests
KSI is tested daily by McAfee Secure to ensure that the Keeper web application and KSI's Cloud Security Vault are secure from known remote exploits, vulnerabilities and denial-of-service attacks. McAfee Secure badges may be found on the Keeper website to verify daily testing of the Keeper website, Web application, and Cloud Security Vault.
A comprehensive external security scan is conducted monthly on the Keeper website, Keeper web application, and Keeper Cloud Security Vault by Trustwave. Keeper staff periodically initiate on-demand external scans through Trustwave.
Certified SOC2 Compliant
Customer vault records are protected using stringent and tightly monitored internal control practices. Keeper is certified as SOC 2 Type 2 compliant in accordance with the AICPA Service Organization Control framework. SOC2 certification helps ensure that your vault is kept secure through the implementation of standardized controls as defined in the AICPA Trust Service Principles framework.
Payment Processing and PCI Compliance
The KSI uses PayPal Payments Pro for securely processing credit and debit card payments through the KSI payment website. PayPal Payments Pro is PCI-DSS compliant transaction processing solution.
KSI is certified PCI-DSS compliant by Trustwave.
The Keeper web client, Android App, Windows Phone App, iPhone/iPad App and browser extensions have been certified EU Safe Harbor compliant with the U.S. Department of Commerce's EU-U.S. Safe Harbor program, meeting the European Commission's Directive on Data Protection.
For more information about the U.S. Department of Commerce U.S.-EU Safe Harbor program, see http://export.gov/safeharbor/index.asp
U.S. Department of Commerce Export Licensed Under EAR
Keeper is certified by the U.S. Department of Commerce Bureau of Industry and Security under Export Commodity Classification Control Number 5D992, in compliance with Export Administration Regulations (EAR).
For more information about EAR: http://www.bis.doc.gov
24x7 Remote Monitoring
Keeper is monitored 24x7x365 by a global third-party monitoring network to ensure that our website and Cloud Security Vault are available worldwide.
If you have any questions regarding this security disclosure, please contact us.
Phishing or Spoofed Emails
If you receive an email purporting to be sent from KSI and you are unsure if it is legitimate, it may be a “phishing email” where the sender's email address is forged or “spoofed”. In that case, an e-mail may contain links to a website that looks like KeeperSecurity.com but is not our site. The website may ask you for your Keeper Security master password or try to install unwanted software on your computer in an attempt to steal your personal information or access your computer. Other e-mails contain links that may redirect you to other potentially dangerous web sites. The message may also include attachments, which typically contain unwanted software called "malware." If you are unsure about an email received in your inbox, you should delete it without clicking any links or opening any attachments.
If you wish to report an e-mail purporting to be from KSI that you believe is a forgery or you have other security concerns involving other matters with KSI, please contact us.
Hosting Infrastructure Certified to the Strictest Industry Standards
The Keeper website and cloud storage runs on secure Amazon Web Services (AWS) cloud computing infrastructure. The AWS cloud infrastructure which hosts Keeper's system architecture has been certified to meet the following third-party attestations, reports and certifications:
SOC 1 / SSAE 16 / ISAE3402
- SOC 2
- SOC 3
- PCI DSS Level 1
- ISO 27001
- FIPS 140-2
Vulnerability Reporting and Bug Bounty Program
Keeper Security is committed to the industry best practice of responsible disclosure of potential security issues. We take your security and privacy seriously are committed to protecting our customers’ privacy and personal data. KSI’s mission is to build world’s most secure and innovative security apps, and we believe that bug reports from the worldwide community of security researchers is a valuable component to ensuring the security of KSI’s products and services.
If you believe that you have found a security vulnerability on a KSI website, web application, mobile app, or desktop application we encourage you to let us know about it right away. We will investigate all legitimate reports and do our best to rapidly fix the problem. Before reporting a suspected security vulnerability, please review this page including our responsible disclosure policy, reporting guidelines, items that should not be reported, and activities that are prohibited.
Responsible Disclosure Policy
If you comply with the policies listed below during the process of reporting a security issue to KSI, we will not initiate a lawsuit or law enforcement investigation against you in response to your report.
- You do not modify or access data of any account if the account owner has not consented to such actions
- You do not violate the privacy of others
- You do not cause the unauthorized access to or destruction of data and/or the interruption or degradation of KSI products and services
- You do not exploit the security issue you discover for any reason, including but not limited to demonstrating additional risk or using the discovered security exploit to seek to discover additional vulnerabilities)
- You do not intentionally violate any other applicable laws or regulations, including (but not limited to) laws and regulations prohibiting unauthorized access to data
- For the purposes of this policy, you are not authorized to access user data or company data, including but not limited to personally identifiable information (PII), personal data (PD), and data relating to an identified or identifiable natural person
- You do not publicly disclose the information without explicit written approval consent by KSI's Director of Security
Bug Bounty Program Eligibility
We recognize and value the community of security researchers that help keep our products and users safe and secure through responsible disclosure of security vulnerabilities. Monetary bounties for such responsibly disclosed reports are entirely at the discretion of KSI and are based on impact, severity, risk, and other factors. To qualify for a bounty you need to first meet the following requirements:
- Adhere to our Responsible Disclosure Policy (see above)
- Report a previously unknown issue
- Report a security bug - a vulnerability in services or infrastructure that creates a security or privacy risk
- Your report must describe a problem in a product or service listed under the bug bounty scope
- If you inadvertently cause or privacy violation or disruption, you must disclose this in your report
- Authentication bypass
- Bugs on customer-facing web applications
- Bugs in desktop applications or mobile apps
- Bugs in third-party assets located by KSI-operated customer-facing web applications
- Cross-site request forgery
- Cross-site scripting (XSS)
- Privilege escalation
- Information disclosure
- Remote code execution
- Timing or enumeration attacks that have a tangible risk to security or privacy
Out of scope / Ineligible for Bug Bounty
- Spam or Email Spoofing
- Social engineering attacks or phishing
- Denial-of-service attacks
- Cookie bugs
- Previously submitted bugs
- Brute-force attacks against locally encrypted data stores
- Bugs that rely on key logging, compromise of the operating system or privileged access
- Bugs on KSI blog sites
- Legacy or unsupported versions of apps
- Use of Keeper to bypass corporate firewalls or network malware detection
Attempting any of the following activities against KSI’s services or infrastructure will result in permanent disqualification and possible criminal investigation and/or legal action. We do not allow any actions that could negatively impact our products or services.
- Code injection on live systems
- Brute force attacks against servers or services
- Disruption or denial-of-service attacks
- Threats, attempts of coercion or extortion of KSI employees, partners, or customers
- Physical attacks against KSI employees, partners, or customers
- Vulnerability scans or automated scans by scanning software tools or third-party scanning services without the explicit written permission of KSI
Bounty and Submission
If you have discovered a security bug that you feel meet the requirements for submission for a bug bounty, and you are the first researcher to report it, we will gladly reward you for your hard work. Bounty payout is based on the severity and impact of the bugs. We do not publish a schedule of bounty payouts, as each bounty is evaluated individually and bounties may vary greatly.
Please follow these steps to submit a security bug for consideration for a bounty payout:
- Email us at “firstname.lastname@example.org” and include the title “Bug Bounty Report”
- Within body of the email, please describe the nature of the bug along with any steps required to replicate it. Please include screenshots if applicable
- Include your full legal name and contact information
- If you feel that your report may be sensitive in nature, we ask that you encrypt your report with our public PGP key