Keeper Encryption Model
Keeper is a Zero Knowledge security provider. Zero Knowledge is a system architecture that guarantees the highest levels of security and privacy by adhering to the following principles:
Data is encrypted and decrypted at the device level (not on the server)
The application never stores plain text (human readable) data
The server never receives data in plain text
No Keeper employee or 3rd party can view the unencrypted data
The keys to decrypt and encrypt data are derived from the user’s master password
Multi-Layer encryption provides access control at the user, group and admin level
Sharing of data uses Public Key Cryptography for secure key distribution
Data is encrypted locally on the user’s device before it is transmitted and stored in Keeper’s Cloud Security Vault. When data is synchronized to another device, the data remains encrypted until it is decrypted on the other device.
Keeper is the most secure, certified, tested and audited password security platform in the world. We are the only SOC 2 and ISO 27001 certified password management solution in the industry and Privacy Shield Compliant with the U.S. Department of Commerce's EU-U.S. Privacy Shield program, meeting the European Commission's Directive on Data Protection. Not only do we implement the most secure levels of encryption, we also adhere to very strict internal practices that are continually audited by third parties to help ensure that we continue to develop secure software and provide the world’s most secure cybersecurity platform.
Keeper implements a multi-layered encryption system based on client-side generated keys. Record-level keys and Folder-level keys are generated on the local device which encrypt each stored Vault record (e.g. Password). For example, if you have 10,000 records in your vault, you also have 10,000 AES Record Keys protecting the data.
Keys are generated locally on the device to preserve Zero Knowledge and to support advanced features such as record and folder sharing. Record and Folder Keys are wrapped by other keys, such as the Data Key and Client Key.
For users who login with a Master Password, a Master Password Key is derived from the Master Password using PBKDF2 and used to unwrap the Data Key, which is then used to unwrap the Record Keys and Folder Keys. Record Keys are then used to decrypt the stored record information in the vault. All fields of the data in each record is encrypted, including file attachments.
For users who login with Keeper SSO Connect (On-Prem), strong Master Password Hashes and Master Password Keys are generated by the on-premise SSO Cloud application.
For users who login with Keeper SSO Connect Cloud, a locally stored Elliptic Curve (EC) key pair is generated locally to encrypt and decrypt the user's Data Key, which then unwraps the Record and Folder keys.
Additional details about the key wrapping is described in the Encryption of Stored Data section below.
Business and Enterprise customers can manage many different capabilities of the Keeper platform, such as role-based enforcement policies, provisioning, authentication and team management.
Administrative functions are protected in the Keeper platform by encryption, in addition to authorization. Authorization allows an Admin to access certain capabilities of the platform, but Encryption is used in many ways to ensure that only designated users are able to physically perform functionality or view sensitive information.
Many features within the Administrative features require decryption of keys in order to function and to preserve Zero Knowledge and Zero Trust. For example:
Teams have a public and private encryption key pair.
Role policies for Vault Transfer and Device Approvals utilize public and private encryption key pairs
Enterprise-level key pairs are used for sharing usage data from the individual user to the Admin
Auditing of Password Strength and other sensitive usage data is encrypted with Enterprise Public Keys that can only be decrypted by the Admin.
Keeper's platform as a whole can be thought of as a key management platform, where the keys are in full control of the users and the Keeper Administrators. The underlying complexity of key management is abstracted from users by the friendly front-end interface.
Keeper has created an advanced cloud authentication and network communications model that has been built for the highest levels of privacy, security and trust. A few key features of the authentication model are:
Master Password is never transmitted over the network layer Unlike most SaaS services, the login credentials never leave the device. PBKDF2 is utilized on the local device to derive a 256-bit AES key used for authentication. Keeper's Cloud Security vault has zero knowledge of the user's authentication credentials
Traffic between client device and Keeper Cloud cannot be intercepted or decrypted Keeper utilizes Key Pinning and additional layers of network-level encryption between the device and the Keeper servers, to ensure that MITM attacks are prevented.
New devices cannot login to an account without a device verification step No login attempts can be made on an account without passing this step. Keeper supports several types of device verification methods that depend on the authentication scheme being used.
2FA is performed after device verification, prior to Master Password entry If a user has 2FA configured or enforced, this step must pass prior to the Master Password entry.
Master Password entry cannot be performed until the Device Verification and 2FA step succeeds The user is unable to proceed to the Master Password entry step without first performing a device verification and 2FA authentication. This advanced authentication flow provides protection against several attack vectors including brute force attack, password spraying, enumeration and MITM.
Keeper provides several methods of authenticating into the platform.
Master Password
SSO (On-Prem) with SAML 2.0
SSO (Cloud) with SAML 2.0
SSO Alternate Master Password
Biometrics
A user cannot attempt to login to an account without a device verification step.
For customers logging in with a Master Password, device verification can be performed using several new methods including:
Email verification code
2FA code entry from a TOTP or text message
Sending a Keeper Push™ message to recognized devices
For customers who authenticate with Keeper SSO Connect Cloud, verification methods include the following:
Keeper Push (using push notifications) to recognized devices
Admin Approval via the Keeper Admin Console
Automatic Admin Approval via Commander CLI
Automatic Admin Approval via Azure Function
2FA can be added to any consumer or business account. Business customers can enforce the use of 2FA with various levels of control and security options.
Starting with version 3 of the Keeper backend API (which corresponds to version 15+ of the Keeper client applications), the 2FA step comes before the Master Password entry. Performing the device verification and 2FA step prior to the Master Password entry phase offers mitigation of several attack vectors including brute force attack, password testing and enumeration.
The default authentication method to Keeper is using a user-selected Master Password. PBKDF2 with 100,000 rounds is used to derive a key ("Master Password Key") which decrypts the user's other keys such as the Data Key. A second key derived from PBKDF2 is used for authentication against the Cloud Security Vault. The ability to authenticate with a Master Password is restricted until the user's device passes verification, and 2FA is verified.
For users who authenticate to Keeper with a SAML 2.0 identity provider, Keeper SSO Connect software is hosted in the customer's environment. The SSO Connect software generates and manages the user's Master Password. The Generated Master Password is then processed with PBKDF2 with 100,000 rounds to derive a key which decrypts the user's other keys such as the Data Key.
Keeper's SSO Cloud capability provides authentication against a SAML 2.0 identity provider, while retaining full Zero Knowledge encryption with the user's vault. An Elliptic Curve key pair is generated on the device. The Data Key of the user is decrypted with the device private key, and the Encrypted Data Key is provided to the user upon successful authentication from their designated identity provider.
Customers who normally login to their Keeper Vault using Enterprise SSO Login (SAML 2.0) can also login to Keeper Web Vault, Browser Extension and Keeper Commander using an "Alternate Master Password". To make use of this capability, it must be enabled by the Keeper Administrator in the role policy and then configured by the user. Offline access can also be achieved with a Master Password for SSO-enabled users when this feature is activated.
This feature may be useful for users for several reasons including:
The requirement to login to the vault in offline mode
The ability to login to the vault if the SSO identity provider is unavailable
Authentication via Keeper Commander CLI (Command Line Interface)
PBKDF2 with 100,000 iterations is used to derive a key from the Alternate Master Password. A hash of the key performs authentication, and the key decrypts the user's Data Key locally on the device. More information is available on SSO Master Password at this link.
Keeper natively supports Windows Hello, Touch ID, Face ID and Android biometrics. Customers who normally login to their Keeper Vault using a Master Password or Enterprise SSO Login (SAML 2.0) can also login to their devices using a biometric. Biometrics must be enabled by the Keeper Administrator in the role policy. Offline access can also be achieved with a biometric for both Master Password and SSO-enabled users when this feature is activated.
When biometric login is enabled on a device, a key is randomly generated locally and stored in the secure enclave (e.g. Keychain) of the device. The user's Data Key is encrypted with the biometric key. Upon successful biometric authentication, the key is retrieved and the user is able to decrypt their vault.
Keeper does NOT store or process biometric data of users. Keeper integrates with the existing biometrics capabilities of the operating system to authenticate the user and retrieve the encryption key protected by the device secure enclave.
For password-based authentication, when users create their account profile, they are required to select a “Master Password”. Users are also able to configure a second factor of authentication using SMS, TOTP, Duo Security, RSA SecurID or SmartWatch.
If the user is authenticated via Keeper SSO Connect™ On-Prem (integration with SAML 2.0 identity provider), the Master Password is auto-generated by the SSO Connect software (hosted and operated by the Enterprise customer on-premise).
If the user is authenticated via Keeper SSO Connect™ Cloud, a 256-bit Elliptic Curve (ECC) private key is generated and stored locally on each device. The ECC private key is used to decrypt the Data Key, and the Data Key decrypts the user's vault. No Master Passwords are utilized in this encryption model.
The Device Private Key is not directly utilized to encrypt or decrypt vault data. Upon successful authentication from the Identity Provider, a separate key (that is not stored) is utilized for decryption of the vault data. Offline extraction of the local Device Private Key cannot decrypt a user's vault.
The Master Password is used to derive an encryption key on the client device using a Password Based Key Derivation Function (PBKDF2) with minimum of 100,000 rounds.
On the client device, a 256-bit AES “Data Key” and “Client Key” are generated, as well as 2048-bit RSA Private Key and Public Key pair.
The “Data Key” is used to encrypt data that is synchronized to the Cloud Security Vault. For Master Password-based authentication, the “Data Key” is encrypted with the “Master Password Key” (derived from the Master Password) and this ciphertext is stored in the Cloud Security Vault. For SSO Cloud-based authentication, the local ECC private key is used to decrypt the Data Key. The Data Key decrypts the user's vault.
The “Client Key” is used to encrypt data that is stored locally on the user’s device. The “Client Key” is encrypted with the “Data Key” and this ciphertext is stored in the Cloud Security Vault. For Master Password-based authentication, the “Client Key” is also encrypted with the “Master Password Key” and this ciphertext is stored locally on the device for offline use. Offline mode can be controlled by the Enterprise administrator.
The vault data stored offline is AES-GCM encrypted with a 256-bit “Client Key” that is generated randomly and protected by PBKDF2-HMAC-SHA512 with up to 100,000 iterations and a random salt. The salt and iterations are stored locally. When the user enters their Master Password, a key is derived using the salt and iterations and an attempt is made to decrypt the Client Key. The Client Key is then used to decrypt the stored record cache.
The “RSA Public Key” is stored directly to the Cloud Security Vault.
The “RSA Private Key” is encrypted with the “Data Key” and the ciphertext is stored in the Cloud Security Vault.
For each record (e.g. Website Password or File) that is created, a 256-bit AES “Record Key” is generated on the client device. The “Record Key” is used to encrypt and decrypt the record content. The “Record Key” is encrypted with the user’s “Data Key” and the ciphertext is stored in the Cloud Security Vault. The Record Key and record data is also encrypted with the “Client Key” and the ciphertext is stored locally on the device.
When a user logs into a device (with their master password), they first decrypt their Client Key from the Master Password-derived key.
The Client Key is used to decrypt all locally stored data on the device.
The data key unwrapped locally or retrieved from the Cloud Security Vault upon successful authentication is decrypted with the user’s Master Password derived key.
Record Key ciphertext is synchronized from the Cloud Security Vault then decrypted locally with the user’s Data Key. Shared Folder keys are decrypted with the respective Shared Folder Key from each folder. Record content is decrypted with the respective Record Key from each record. Record Keys and content are then encrypted with the client key and stored locally.
To share a Keeper Record to another user, Keeper first requests the user’s RSA or Elliptic Curve Public Key from the Cloud Security Vault.
Keeper is transitioning from RSA to Elliptic Curve and utilize both methods for various features.
The Record Key of each record is encrypted with the recipient’s RSA or Elliptic Curve Public Key and synchronized to the user’s Keeper vault via the Cloud Security Vault.
The recipient of the encrypted shared record decrypts the Record Key with their RSA or Elliptic Curve Private Key. For optimization, the Record Key will be re-encrypted with the user’s Data Key (since AES encryption is faster than RSA encryption) and the ciphertext is stored in the recipient’s Cloud Security Vault.
For subsequent record retrievals, the recipient decrypts the Record Key with their Data Key, and then decrypts the record content with the Record Key.
The Keeper Cloud Security Vault is protected by an API which authenticates each request from the client device. On the client device, a 256-bit "Authentication Key" is derived from the Master Password using PBKDF2-HMAC-SHA256 and a random salt. An "Authentication Hash" is generated by hashing the "Authentication Key" using SHA-256. To login, the Authentication Hash is compared against a stored Authentication Hash on the Cloud Security Vault. After login, a session token is generated and used by the client device for subsequent requests. This authentication token must be renewed every 30 minutes, or upon the request of the server.
KSI supports 256-bit and 128-bit TLS 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 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 supports the following TLS cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Keeper client devices also implement Key Pinning, a security mechanism which prevents impersonation by attackers using fraudulent digital certificates.
To protect against unauthorized access to a customer's 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 Settings screen of the Keeper Web App, Desktop App or mobile application. 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.
Keeper supports FIDO-compatible U2F hardware-based security key devices such as YubiKey and Google Titan keys 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.
Keeper operates a self-contained managed service architecture on Amazon AWS called BreachWatch which is physically separate from the Keeper Backend API and stored user data.
On the BreachWatch servers, a physical Hardware Security Module (HSM) is used to process, hash and store billions of unique passwords from dark web data breaches. Each of these billions of passwords is processed on Keeper's servers using HMAC_SHA512 hashing method, hashed with a Hardware Security Module using a non-exportable key.
On the Keeper end-user client device, when BreachWatch is activated, a HMAC_SHA512 hash is generated based on each stored password and sent to the server. On the server, a second hash is created using HMAC_SHA512 via the Hardware Security Module (HSM) using a non-exportable key. Hashes are compared to determine if a password has been breached.
BreachWatch backend architecture was built to prevent correlation of a breached password to an actual password in the user's vault, no matter the size of the data breach. The hashing used in the breached password detection utilizes a physical Hardware Security Module to ensure that hashing can only be performed online - to prevent any threat of brute force attack on the BreachWatch data.
The below system diagram outlines the overall data flow, encryption and BreachWatch hash processing workflows.
Keeper SSO Connect Cloud provides Keeper Enterprise customers with a method of authenticating a user and decrypting stored data in a zero-knowledge encrypted vault, with authentication provided through a 3rd party identity provider (IdP) utilizing standard SAML 2.0 protocols in a fully cloud environment.
In this implementation, a 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. Each user has their own 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.
The importance of this new capability is that the user can decrypt their vault using an encrypted key stored in the Keeper cloud. Zero knowledge is preserved because the Keeper cloud is unable to decrypt the user's Data Key on their device. The Data Key ("DK") of the user is decrypted with the device private key ("DPRIV"), and the Encrypted Data Key ("EDK") is provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS).
For SSO Connect Cloud users, an Elliptic Curve private key is generated and stored locally on each device. For Chromium-based web browsers, the Keeper Vault stores the local device EC private key ("DPRIV") as a non-exportable CryptoKey. On iOS and Mac devices, the key is stored in the device KeyChain. Where available, Keeper utilizes secure storage mechanisms.
The Device Private Key is not directly utilized to encrypt or decrypt vault data. Upon successful authentication from the Identity Provider, a separate key (that is not stored) is utilized for decryption of the vault data. Offline extraction of the local Device Private Key cannot decrypt a user's vault.
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. New devices generate a new set of public/private keys, and the approving device encrypts the user's data key with the public key of the new device. The new device’s encrypted data key (EDK) is provided to the requesting user/device and then the user is able to decrypt their data key, which then decrypts the user's vault data. Within the decrypted vault data the user can decrypt their other private encryption keys such as record keys, folder keys, team keys, etc.
The importance of this capability is that the user can decrypt their vault using an encrypted key stored by the Keeper cloud, and does not require any on-prem or user-hosted application services to manage the encryption keys. Zero knowledge is preserved because the Keeper cloud is unable to decrypt the user's Data Key on their device. The Data Key of the user is decrypted with the device private key (DPRIV), and the EDK is only provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS).
From an administrator's perspective, the benefits are: easy setup and no required hosted software to manage encryption keys as described in Keeper's current SSO Connect encryption model.
The only workflow change in this model (compared to on-prem implementation of Keeper SSO Connect) is that the user must perform new device approval on an active device, or delegate the responsibility to a Keeper Administrator to perform device approval.
Keeper SSO Connect Cloud supports 4 different device approval methods:
1) Keeper Push
2) Admin Approval via the Keeper Admin Console
3) Admin Approval via Commander automation tool
4) Automatic Admin Approval via Azure Function
Learn more about SSO Cloud Device Approvals here: https://docs.keeper.io/sso-connect-cloud/device-approvals
Q: Can Keeper's employees see our stored data?
A: NO. We are Zero Knowledge and cannot decrypt customer data.
Q: Where are master passwords and encryption keys stored?
A: The Master Password is not stored and the encryption keys derived from the master password are not stored. When the user types in their Master Password, a key is derived in real time using a password derivation function known as PBKDF2 with 100,000 rounds. This key then unwraps the ciphertext to extract the Data Key which then unwraps the folder keys, record keys and record data.
Q: How does biometric login work?
If biometrics are activated and allowed by the Admin, a AES-256 "biometric key" is generated locally on the device and then stored in the iOS Keychain. When the user successfully authenticates with the operating system using Face ID or Touch ID authentication, the key is provided to the Keeper application and used to unwrap the stored ciphertext to retrieve the Data Key.
Keeper natively supports Windows Hello, Touch ID, Face ID and Android biometrics. Customers who normally login to their Keeper Vault using a Master Password or Enterprise SSO Login (SAML 2.0) can also login to their devices using a biometric. Biometrics must be enabled by the Keeper Administrator in the role policy. Offline access can also be achieved with a biometric for both Master Password and SSO-enabled users when this feature is activated.
Q: How do you protect against brute force password attack?
A: Keeper has implemented multiple layers of protection against password stuffing and password brute force attack. We do not permit login on any device that has not been approved. Once approved, the first step is 2FA. One 2FA passes, only then can a user attempt a password test. After 10 failed password attempts, the account will become exponentially locked with each attempt. Keeper's self-destruct mechanism can also be enabled on the local device to delete locally stored data on 5 failed attempts. Read more about our Login API at this link.
Q: How do you protect against 2FA attack?
A. Keeper does not permit login on any device that has not been approved. Once a device is approved (either through email verification, Keeper Push or 2FA code entry), the user will be prompted with 2FA. Keeper will lock an account after 10 failed 2FA attempts on an exponential basis for each failed attempt.
Q: How do you protect against enumeration attack?
The Login API V3 makes major strides in the prevention of user enumeration against the Keeper cloud infrastructure. This means that the server will not disclose the existence or non-existence of a user's account. Enumeration is denied unless the user is logging in from a trusted/known device or IP.
Since Keeper operates several isolated data centers and enumeration between data centers is denied, there are some cases when a user must perform round trips and email verifications if they attempt to login from the wrong data center. Since disclosures cannot be made through the web interface, emails are utilized to communicate login and redirection.
Q: How do you enforce policies without having access to the data?
A: When the user logs into their device, all of the Enterprise policies are downloaded from the Keeper Cloud and processed locally on the device for policies that require record-level filtering, URL filtering or password-specific rules and processing.
Q: Why does Keeper have a Security Question and Answer as account recovery?
Account recovery can be disabled by the customer in the role policy section of the Admin Console. This may be desired if you are using SSO Cloud which utilizes a 3rd party identity provider. The way account recovery works (with the Security Question method) is by storing a second copy of the user's data key that is encrypted with the selected Security Answer. To complete a vault recovery, the user is required to enter an email verification code, and also the Two-Factor Authentication code (if enabled on the account). We recommend creating a strong security question and answer, as well as turning on Keeper's Two-Factor Authentication feature from the 'Settings' screen. From a security perspective, Keeper finds that a strong security answer paired with email and 2FA verification provides the balance between convenience and security. Enterprise customers who wish to disable account recovery and rely on the "Vault Transfer" admin feature are able to set this policy. Note that if account recovery is disabled, Vault Transfer is the only way that a user can be recovered if they forget their Master Password or if they lose access to the SSO IdP.
Q: How do I offboard an employee and gain access to their vault?
Business and Enterprise customers are provided a zero-knowledge method of account recovery for their users using Keeper's Account Transfer policy. This is described in detail at this link.
Full Security Disclosure https://keepersecurity.com/security.html
GDPR Compliance https://keepersecurity.com/GDPR.html
White Papers, Data sheets and Case Studies https://keepersecurity.com/resources.html
SSO Connect Cloud Security Model https://docs.keeper.io/sso-connect-cloud/security-and-user-flow Additional technical documentation is available under NDA.
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. Keeping our users secure is core to our values as an organization. We value the input of good-faith cybercriminals and believe that an ongoing relationship with the researcher community helps us ensure their security and privacy, and makes the Internet a more secure place. This includes encouraging responsible security testing and disclosure of security vulnerabilities.
Keeper's Vulnerability Disclosure Policy sets out expectations when working with researchers, as well as what you can expect from us.
If security testing and reporting is done within the guidelines of this policy, we:
Consider it to be authorized in accordance with Computer Fraud and Abuse Act,
Consider it exempt from DMCA, and will not bring a claim against you for bypassing any security or technology controls,
Consider it legal, and will not pursue or support any legal action related to this program against you,
Will work with you to understand and resolve the issue quickly, and
Will recognize your contributions publicly if you are the first to report the issue and we make a code or configuration change based on the issue.
If at any time you are concerned or uncertain about testing in a way that is consistent with the Guidelines and Scope of this policy, please contact us at [email protected] before proceeding.
To encourage good-faith security testing and disclosure of discovered vulnerabilities, we ask that you:
Avoid violating privacy, harming user experience, disrupting production or corporate systems, and/or destroying data,
Perform research only within the scope set out below, and respect systems and activities which are out-of-scope,
Contact us immediately at [email protected] if you encounter any user data during testing, and
You give us reasonable time to analyze, confirm and resolve the reported issue before publicly disclosing any vulnerability finding.
Keeper has partnered with Bugcrowd to manage our vulnerability disclosure program. Please submit reports through [https://bugcrowd.com/keepersecurity].
