Keeper Encryption and Security Model Details
The full details of Keeper’s encryption and security model are outlined below, with block diagrams, implementation details and additional resources.
Last updated
The full details of Keeper’s encryption and security model are outlined below, with block diagrams, implementation details and additional resources.
Last updated
Keeper is a Zero Knowledge security provider. Zero Knowledge is a system architecture that guarantees the highest levels of security and privacy. Encryption and decryption of data always occurs locally on the user's device.
Our encryption model adheres to the following structure:
Each vault record is encrypted by a unique and client-side generated 256-bit AES encryption key in GCM mode.
Each record-level key is wrapped by a 256-bit AES Shared Folder key if it is contained within a Shared Folder.
For Vault users, the Record and Folder Keys are encrypted with another AES-256 key called the Data Key.
For Secrets Manager users, the Record and Folder Keys are encrypted with a 256-bit AES Application Key.
For users who login with a Master Password, the keys to decrypt and encrypt data are derived from the user’s master password.
For users who login with SSO or Passwordless technology, Elliptic Curve cryptography is used to encrypt and decrypt data at the device level.
All encrypted payloads sent to the Keeper servers are additionally wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the client device and transferred to the server using ECIES encryption via the server's public EC key.
Sharing of secrets between users uses Elliptic Curve Cryptography for secure key distribution.
Multi-Layer encryption provides access control at the user, group and admin level.
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. Keeper has the longest-standing SOC 2 and ISO certifications in the industry. Keeper is ISO 27001, 27017 and 27018 certified. Keeper is GDPR compliant, CCPA compliant, HIPAA compliant, FedRAMP and StateRAMP Authorized, PCI DSS certified and certified by TrustArc for privacy.
Keeper complies with the EU-U.S. Data Privacy Framework (“EU-U.S. DPF”), the UK Extension to the EU-U.S. DPF and the Swiss-U.S. Data Privacy Framework (“Swiss-U.S. DPF”) as set forth by the U.S. Department of Commerce. 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 is GDPR compliant and we are committed to ensuring our business processes and products continue to maintain compliance for our customers in the European Union.
Our Privacy Policy can be found here:
https://www.keepersecurity.com/privacypolicy.html
Keeper's desktop applications, web applications and mobile applications do not contain any trackers or 3rd party libraries which perform tracking. As an example, see this link for information on Keeper's Android app which shows that no trackers are installed.
Keeper is a fully SaaS platform and currently hosts data in the following Amazon AWS data centers. Customer may host their Keeper tenant in any preferred primary region. Customer data (stored ciphertext) and access to the platform is isolated to the specific region.
United States (US)
United States Government Cloud (US_GOV)
Europe (EU)
Australia (AU)
Japan (JP)
Canada (CA)
Keeper utilizes FIPS 140-3 validated encryption modules to address rigorous government and public sector security requirements. Keeper’s encryption has been certified by the NIST CMVP and validated to the FIPS 140 standard by accredited third party laboratories.
Keeper has been issued certificate #4743 under the NIST CMVP:
Keeper Security Government Cloud (KSGC) is KSI’s password management and cybersecurity platform for public sector agencies. KSGC is a FedRAMP Authorized provider at the Moderate Impact Level, hosted in AWS GovCloud (US). KSGC can be found on the FedRAMP Marketplace.
The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. federal government program that provides a standardized approach to security assessment, authorization and continuous monitoring for cloud products and services. FedRAMP enables government agencies to use modern cloud technologies, with an emphasis on security and protection of federal information and helps accelerate the adoption of secure, cloud solutions. For more information about FedRAMP, please visit https://www.gsa.gov/technology/government-it-initiatives/fedramp.
KSGC supports compliance with the United States International Traffic in Arms Regulations (ITAR). Companies that are subject to ITAR export regulations must control unintended exports by restricting access to protected data to U.S. Citizens and by restricting physical location of protected data to the U.S.
KSGC’s FedRAMP Moderate environment supports ITAR requirements through the following:
Fully compliant data storage hosted on AWS GovCloud and restricted to the U.S.
Secure data encryption in transit and at rest.
Zero-knowledge and zero-trust security, in conjunction with granular permissions, allows organizations to ensure that only approved personnel can access sensitive data.
Robust compliance reporting features provide a traceable, electronic audit trail of all actions performed and data entered.
Sequestered Customer Success team is comprised of U.S. Persons specifically trained in safe handling of Export Controlled and ITAR-governed data.
No non-U.S. based support.
The Keeper FedRAMP environment has been audited by an independent third-party assessment organization (3PAO) to validate that proper controls are in place to support customer export compliance programs.
For more information about ITAR, please visit https://www.pmddtc.state.gov/.
Keeper's platform is built with End-to-End Encryption (E2EE) across all devices and endpoints. As described in this technical architecture document:
Data stored in the platform is encrypted locally and encrypted in transit between the user's devices
Information exchanged between Keeper users is encrypted from vault-to-vault
Data at rest is encrypted with multiple layers, starting with AES-256 encryption at the record level
Data in transit is encrypted with TLS and additional layers of transmission encryption which protects against access MITM, service providers and untrusted networks.
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.
All fields and all of the data in the vault is encrypted, including file attachments.
For users who login with a Master Password:
A Master Password Key is derived from the Master Password using PBKDF2 with 1,000,000 rounds and used to unwrap the AES-256 Data Key, which is then used to unwrap the AES-256 Record Keys and Folder Keys. Record Keys are then used to decrypt the stored record information in the vault.
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.
For users who login with Keeper SSO Connect (On-Prem):
Master Password Hashes and 256-bit AES Master Password Keys are generated by the on-premise SSO Cloud application.
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 decryption. A second PBKDF2 key is generated locally and then hashed with HMAC_SHA256 to derive an authentication token. Keeper’s Cloud Security vault has zero knowledge of the user’s decryption key.
Traffic between client device and Keeper Cloud cannot be intercepted or decrypted Keeper utilizes Key Pinning and additional layers of network-level encryption (Transmission Keys) 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 approval and 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, device approval performs a key transfer, in which the user's encrypted data key is delivered to the device, which is then decrypted locally using their elliptic curve private key. Device approval methods include the following:
Keeper Push (using push notifications) to existing user devices
Admin Approval via the Keeper Admin Console
Automatic approval via Keeper Automator service
Automatic Admin Approval via Commander CLI
Automatic Admin Approval via Azure Function
Learn more about device approvals at this link.
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 account enumeration.
The user's vault records are encrypted locally with a 256-bit AES-GCM "Record Key" that is randomly generated on the device. The record keys are encrypted with a 256-bit AES-GCM "Data Key" that is also generated randomly on the user's device and unique to each user. For users who login with a Master Password, the Data Key is encrypted with a key derived from the user's Master Password using PBKDF2-HMAC-SHA256 with a 128-bit random salt and 1,000,000 iterations. The encrypted vault ciphertext is stored in the Keeper cloud.
For authentication, a second PBKDF2 key is generated locally on the user's device using 1,000,000 iterations and a 128-bit randomly generated salt. This key is then hashed with SHA256 to derive an authentication token. In the Keeper cloud, the authentication token is super-encrypted with a "user authentication" key. The user authentication key is randomly generated by the server and encrypted with a hardware security module (with a non-exportable key) prior to storage. The user authentication key is used to encrypt the salt, authentication token, user’s encrypted data key and other authentication related fields for alternate authentication methods like biometrics, etc.
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 (secp256r1) private key 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.
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 to derive a key which decrypts the user's other keys such as the Data Key.
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 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 or Keystore) 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 FIDO2 WebAuthn, TOTP, Duo Security, RSA SecurID, SMS or SmartWatch.
If the user is authenticated via Keeper SSO Connect™ Cloud, a 256-bit Elliptic Curve (EC secp256r1) private key is generated and stored locally on each device. The EC device private key is used to decrypt the AES-256 Data Key, and the Data Key decrypts the user's vault record keys and folder keys. No Master Passwords are utilized in this encryption model.
If the user is authenticated via Keeper SSO Connect™ On-Prem (integration with SAML 2.0 identity provider), the Master Password and AES-256 key is auto-generated by the SSO Connect software (hosted and operated by the Enterprise customer on-premise).
The EC 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 1,000,000 rounds.
On the client device, a 256-bit AES “Data Key” and “Client Key” are generated, as well as the User's EC Private/Public Key Pair for the purpose of sharing records between users and teams. (For legacy compatibility with older shared records, a 2048-bit RSA Private/Public Key Pair is also generated).
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 using PBKDF2 with 1,000,000 iterations) and this ciphertext is super-encrypted and stored in the Cloud Security Vault. For SSO Cloud-based authentication, the local Device EC (secp256r1) private key is used to decrypt the Data Key. The Data Key decrypts the user's vault cipher record keys
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 through role enforcement policies.
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 a 128-bit random salt and 1,000,000 iterations. 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 "Device EC Public Key" is stored directly to the Cloud Security Vault.
The “Device EC Private Key” is stored locally on the device and never leaves the device. This is used for Cloud SSO authentication models.
The "User EC Public Key" is stored directly to the Cloud Security Vault.
The “User EC 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 Elliptic Curve Public Key from the Cloud Security Vault.
The Record Key of each record is encrypted with the recipient’s 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 Elliptic Curve Private Key. For optimization, the Record Key will be re-encrypted with the user’s Data Key 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.
Note that for legacy compatibility with Keeper's legacy "general" record type, a 2048-bit RSA Private/Public Key Pair is also utilized.
For all cryptographic functions in the Keeper client device, a secure random number generator is utilized. For example, on web-based applications like the Keeper Web Vault and Browser Extensions, the getRandomValues method of the Web Crypto API is used. On iOS, the SecRandomCopyBytes method is used. On Android, SecureRandom is used.
The Keeper Cloud Security Vault is protected by APIs which are validated through authorization by the client device. The client retrieves a session token upon login and sends it with each API call. The session token is tracked on the server. Login is performed either by a Master Password, session resumption, or SAML 2.0 SSO authentication.
When using a Master Password, the client device derives a 256-bit "Authentication Key" using PBKDF2-HMAC-SHA256 with 1,000,000 iterations and a 128-bit 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 on the server and sent to the client to be used by the client device for subsequent API requests. The session must be active to allow continued use of client to server communications.
KSI supports 256-bit and 128-bit TLS (1.3 and 1.2) to encrypt all data transport between the client application and KSI's cloud-based storage.
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 (as of October 2023, using AWS security policy ELBSecurityPolicy-TLS13-1-2-2021-06):
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
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 Passkeys and FIDO2-compatible WebAuthn 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. These Hashes-of-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.
In summary:
The passwords are hashed twice with HMAC_512 - once on the client device using a "pepper", and once in the Amazon AWS CloudHSM, using a hardware security module with a non-exportable key.
HMAC_512 is utilized because it takes advantage of a strong hashing function, plus a secret key (which is not exportable). Therefore, an offline attack against the hashes is not feasible.
"Message authentication code" (MAC) with the result of a cryptographic hash function. It is a way to expand the use of hash functions. Its results depend not only on the message but on a second input that can be a secret key.
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 Device-Encrypted Data Key ("DEDK") is provided to the user upon successful authentication from their designated identity provider (e.g. Okta, Azure, AD FS, Google Workspace, Duo, Ping, JumpCloud, etc...).
The data key, sharing key pair and device EC private/public key pair is generated
Data Key is encrypted with the device EC public key and stored in the cloud (DEDK)
The user logs in with their identity provider (IdP)
After IdP login, the signed SAML assertion is verified by Keeper The vault is created and user is onboarded
The user logs in with their identity provider (IdP).
After IdP login, the signed SAML assertion is verified by Keeper.
Keeper delivers the device-encrypted data key (DEDK) to the user.
The data key is decrypted with the device EC private key.
The data key decrypts the folder keys and record keys.
Record keys decrypt the record contents.
On every new device, an EC private/public key pair is generated.
The user logs in with their identity provider (IdP).
After IdP login, the signed SAML assertion is verified by Keeper.
Device is “approved” via Keeper Push, Admin Approval or Automator service (*see Device Approval below).
In the approval process, the data key is encrypted with the public key of the new device.
The device-encrypted data key (DEDK) is sent to the user.
A device approval is a mechanism to securely deliver the user’s data key to their new device with zero knowledge.
A user can approve their device by encrypting the data key with the new device public key.
An admin can approve the device from the Admin Console, Commander or automated approval system.
Admin decrypts the user’s data key and re-encrypts the data key with the new device public key.
The Automator service can perform automated device approvals on the customer’s infrastructure.
The Automator service checks the SAML signature, unwraps the data key, encrypts the data key with the new device public key.
Read more about the Automator service at https://keeper.io/automator
For SSO Connect Cloud users, an Elliptic Curve private key is generated and stored locally on each device. For Chromium-based web browsers and Keeper Desktop, 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. On Android devices, the key is encrypted with the Android Keystore, utilizing EncryptedSharedPreferences. Where available, Keeper utilizes secure storage mechanisms on each operating system.
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. Therefore, 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 several 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
(5) Automatic Approval using Keeper Automator (** Recommended)
Learn more about SSO Cloud Device Approvals here: https://docs.keeper.io/sso-connect-cloud/device-approvals
The system architecture diagram for Keeper SSO Connect is shown below:
Keeper provides account recovery using a randomly generated 24-word recovery phrase. The recovery phrase can be used to regain access to your Keeper Vault in case you forget your Master Password.
Keeper implements recovery phrases using the industry-standard BIP39 word list, which is a set of 2,048 words used to generate an encryption key with 256 bits of entropy. Each word in the BIP39 list is carefully chosen to improve legibility and make the recovery process less error-prone.
The recovery phrase is generated locally on the user's device using the BIP39 word list. Keeper's backend systems do not have access to this recovery phrase, nor do any employees of Keeper. Keeper is a zero-knowledge platform and we cannot assist in the recovery process.
Recovery Phrase account recovery works by storing a second copy of the user's data key encrypted with a 256-bit AES-GCM key. This key is derived using HKDF with HMAC_SHA512 as the underlying hashing algorithm, from the 24 randomly-selected words on the BIP39 list.
To complete a vault recovery, the user is required to:
Enter an email verification code
Pass the Two-Factor Authentication step (if enabled on the account)
Enter the recovery phrase locally on the device
Keeper Secrets Manager is a Zero Knowledge platform for DevOps, IT Security and software development teams to manage secrets throughout the software development and deployment lifecycle.
Secrets Manager adheres to the following encryption model:
(1) Secrets are encrypted and decrypted on the device (not on the server)
(2) The device never stores plain text (human readable) data
(3) The server never receives data in plain text
(4) No Keeper employee, 3rd party or intermediary can decrypt secrets
(5) The keys to decrypt and encrypt secrets are managed by the customer on the Client Device.
(6) Each secret is encrypted by a unique and client-side generated 256-bit AES encryption key in GCM mode.
(7) Each record-level key is wrapped by a Shared Folder key if it is contained within a Shared Folder.
(8) A client-side generated 256-bit AES Application Key is used to decrypt the Shared Folder and Record Keys. The record key decrypts the individual secret.
(9) All encrypted payloads sent to the Keeper servers are additionally wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the client device and transferred to the server using ECIES encryption via the server's public EC key.
(10) Sharing of secrets between users uses Elliptic Curve Cryptography for secure key distribution.
(11) Multi-Layer encryption provides access control at the user, group and admin level.
(12) Secrets that are managed within a User Vault are segmented and isolated to defined Secrets Manager devices that are granted access to the individual records and folders.
For more specific security details regarding Keeper Secrets Manager, see this page.
To learn more about Secrets Manager see the documentation.
Keeper "One-Time Share" provides time-limited secure sharing of a record (such as a password, secret, document or other confidential information) to a recipient without having to create a Keeper account. The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.
(1) In the vault, the sharer generates a one-time access token by clicking on "One-Time Share" in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.
(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the "fragment identifier" section of the URL which is never sent over the network to Keeper's servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.
(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).
(4) Upon loading the URL, the recipient's device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser's CryptoKey storage.
(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.
(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser's CryptoKey storage or other designated storage location.
(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client's requests must be signed with the Client Private Key.
(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.
(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.
The Keeper Gateway is a service that is installed on-premise in order to execute rotation, discovery, connections and tunneling to line of sight devices. The Keeper Gateway communicates outbound to the Keeper Router using WebSockets and Keeper Secrets Manager zero-knowledge protocols.
The Keeper Gateway authenticates first to the Keeper Router using the One Time Access Token provided upon installation of the Gateway service on the target machine. After the first authentication, subsequent API calls to the Router authenticate using a Client Device Identifier (which is the HMAC_SHA512 hash of the One Time Access Token).
For accessing and decrypting vault records, the Keeper Gateway uses standard Keeper Secrets Manager APIs which perform client-side encryption and decryption of data. The security model of Keeper Secrets Manager ensures least privilege and zero knowledge by allocating only specific folders and records that can be decrypted by the service. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device.
Like any other Secrets Manager device, access can also be restricted based on IP address in addition to the encryption and signing process.
The Keeper Gateway is installed into the customer's environment which establishes an outbound secure connection to the Keeper Router, enabling bi-directional communication to the Keeper cloud without any network configuration. Keeper Router makes cloud access to on-prem infrastructure easy and secure by utilizing WebSockets for the inbound requests.
With Keeper, WebSockets are established between the end-user device (e.g. Web Vault) and the Keeper Router using the user's current session token. The session token is verified by the Keeper Router to authenticate the session. All encrypted payloads sent to the Keeper Router are wrapped by a 256-bit AES transmission key in addition to TLS, to protect against MITM attacks. The transmission key is generated on the end-user device and transferred to the server using ECIES encryption via the Router's public EC key.
When a user on their Web Vault or Desktop App triggers a password rotation, discovery job or remote connection, the message flow is the following:
Upon installation of the Gateway, it authenticates with the Keeper Cloud using a hashed One Time Access Token one time. The client signs the payload and registers a Client Device Public Key with the server on the first authentication. After the first authentication, subsequent requests are sent to the Keeper Router and signed with the Client Device Private Key.
The Gateway establishes an authenticated WebSocket connection using the Client Device Private Key and ECDSA signature.
The Vault sends a message to the Keeper Router with a command to execute (rotation, discovery, connection) and authenticates the command using the user's active session token.
The Vault only transmits command and control messages, for example: Rotate UID XXX. No secret information is communicated between Vault and Router. The Router authenticates the command using the session token of the record's rotation configuration to validate the user's request.
The Router relays the command to the destination gateway through the existing WebSocket connection.
The Gateway retrieves secrets, admin credentials, record details and other private data by using Keeper Secrets Manager APIs. API requests to the Keeper Cloud are sent with a Client Device Identifier and a request body that is signed with the Client Device Private Key. The server checks the ECDSA signature of the request for the given Client Device Identifier using the Client Public Key of the device. The Client Device decrypts the ciphertext response from the server with the Application Private Key, which decrypts the Record Keys and Shared Folder Keys. The Shared Folder Keys decrypt the Record Keys, and the Record Keys decrypt the individual Record secrets.
The Gateway uses Keeper Secrets Manager "update" commands to update the user's vault with any password or discovery job updates.
After a rotation or discovery job is complete, the Gateway informs the Router that the job is complete. ARAM event logs are triggered by the Router.
The Keeper Router architecture is Zero Knowledge, and Keeper's infrastructure never has the ability to access or decrypt any of the customer's stored vault data.
Zero-Trust KeeperPAM provides the capability to establish cloud and on-prem privileged sessions, create tunnels, establish direct infrastructure access and secure remote database access without a VPN.
A Connection is a visual remote session using the web browser. Interaction between the user and the target device is with a web browser window or within the Keeper Desktop application.
A Tunnel is a TCP/IP connection that is established between the local vault client through the Keeper Gateway to the target endpoint. The user can utilize any native application for communicating with the target endpoint, such as the command-line terminal, GUI application or database management application such as MySQL Workbench.
When the user establishes a connection or tunnel:
(1) The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record.
(2) The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
(3) The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
(4) For Connections, the Vault Client (using the Keeper Connection Manager guacd protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses Guacd to connect to the destination found in the Keeper record.
(5) For Tunneling features (port forwarding), a local port is opened up on the local device running Keeper Desktop software. Data sent to the local port is transmitted through the WebRTC connection to the Keeper Gateway and subsequently forwarded to the target endpoint defined in the Keeper record.
(6) Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.
Keeper Remote Browser Isolation technology protects access to internal web applications or any other web-based asset through the Keeper Connection Manager docker container or through the Keeper Gateway.
Using the Connection Manager docker container method:
(1) The user authenticates into the Keeper Connection Manager web service, hosted by the customer in a Docker container.
(2) The user launches a remote browser isolation session to the target web application. Between the user's browser and the hosted Keeper Connection Manager web service, communication over HTTPS is protected by Let's Encrypt or the customer's specified certificate.
(3) On the Keeper Connection Manager docker container, a virtualized version of Chromium is executed within a sandbox, the resulting HTTP traffic from the container to the target website is routed through a local display driver then forwarded to the user's web browser using the Apache Guacamole ("guacd") protocol.
Using the Keeper Gateway with the Keeper Web Vault or Desktop App:
(1) The Vault Client application communicates to the Keeper Router infrastructure to initiate a WebRTC connection that is protected by a ECDH symmetric key that is stored inside the relevant Keeper record.
(2) The Keeper Gateway communicates with the Keeper Router through outbound-only WebSockets. This is described in detail at this link.
(3) The Keeper Gateway utilizes Keeper Secrets Manager APIs to retrieve the necessary secrets from the vault, including the ECDH symmetric key.
(4) The Vault Client (using the Keeper Connection Manager guacd protocol) passes data through the WebRTC connection to the Keeper Gateway that then uses the Apache Guacamole ("guacd") protocol to connect to the destination found in the Keeper record.
(6) Session recordings of connections are protected by an AES-256 encryption key ("recording key") which is generated on the Keeper Gateway on every session. The recording key is additionally wrapped by a HKDF-derived AES-256 resource key.
Browser Isolation Protection
Several security measures are activated by using the Remote Browser Isolation protocol:
(1) The web application endpoint being protected is wrapped by a layer of TLS encryption from the Keeper Connection Manager gateway to the user's local device, regardless of whether TLS is used between gateway and endpoint - protecting against MITM attack or packet inspection on the user's local network.
(2) The remote browsing session is visually projecting the interaction to the user's local device using a canvas and graphical rendering. No javascript code or HTML is rendered on the user's local machine.
(3) Since no website code from the target is executed locally and the local browser cannot directly access the underlying application code, the isolated web application is protected against attack vectors such as reflected cross-site scripting vulnerabilities, cross-site request forgery, and API abuse.
(4) The end user can be restricted from performing data exfiltration from the target endpoint through URL and resource request filtering. File uploads and downloads are restricted, even if the web application attempts to perform the action.
(5) The browsing session and keystrokes can be recorded for auditing and compliance purposes, providing the ability to perform forensic analysis of web-based sessions.
(6) Credentials that are auto-filled from the gateway into the target web application are never transmitted to the user's device, and are not accessible by the user on their local device, protecting against secret leakage.
(7) Through firewall policies, the user can be required to access the target web application only through the remote browser isolation session, reducing the threat from a compromised browser or local device malware.
(8) The target web application becomes protected by Single Sign-On and/or MFA authentication, even if the application does not natively support it. Keeper protects access to the vault and any remote browser isolation sessions through the advanced authentication methods described in this document.
When Account Transfer Policy is activated for a role, a role enforcement policy public/private key pair is generated on the Admin Console locally. The end-user's data key (for users in a role to which the enforcement is applied) is encrypted with the role enforcement policy's Public Key when the user signs into the Vault. The role enforcement private key is encrypted with the Admin's Public Key. Therefore, the Admin can decrypt the role enforcement private key when a vault transfer is required.
To perform a Vault Transfer, the Keeper Admin first must lock the user's account, then the transfer can occur which immediately is followed by deleting the user's account. This ensures the operation is not performed secretly. When performing the transfer, the user's Data Key is retrieved by first unwrapping the role enforcement Private Key and then unwrapping the user's Data Key. The Data Key is then used to unwrap the record keys, team keys, and folder keys.
All encryption is performed client side within the Admin Console, 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 Data Key shared. Therefore, the data cached on a user’s device cannot be decrypted without the user’s master password. 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. Although the record, folder and team keys are compromised to the admin during the transaction, the keys are not usable for gaining access to the underlying record or folder 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.
Learn more about the account transfer policy.
Keeper's consumer product 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. 2048-bit 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 key pair) to accept the invitation.
Digital Legacy is only supported on consumer-level accounts
Keeper's mobile apps do not contain any trackers. All mobile apps go through vulnerability testing with Keeper's 3rd party testers and the Bugcrowd bug bounty program.
Exodus Privacy is an organization that monitors the applications that perform user tracking. Keeper's Android application is listed below:
https://reports.exodus-privacy.eu.org/en/reports/com.callpod.android_apps.keeper/latest/#trackers
The Keeper Browser extension ("KeeperFill") provides customers with autofill capabilities on all web browsers including Chrome, Firefox, Edge, Safari and other chromium-based browsers.
When users login to Keeper using a Master Password: A key is derived from the Master Password using PBKDF2. This key, called the "Master Password Key", is NOT stored anywhere. It is used to decrypt the AES-256 Client Key and the AES-256 Data Key. The Data Key is used to decrypt the data coming from the Keeper Cloud, and the Client Key is used to encrypt and decrypt the ciphertext stored locally.
After the user's ciphertext is sync'd from the Keeper Cloud to the local device, the ciphertext is decrypted locally using the Data Key and then encrypted using the Client Key into the device's local IndexedDB database. The browser IndexedDB database is only available to the Keeper browser extension.
At no time is Keeper storing the encryption key used to decrypt the local ciphertext. The information is held in memory while the user is logged in, and used for auto-fill and accessing the Keeper browser toolbar functionality. When the Service Worker is restarted, Keeper repeats the process of decrypting data from IndexedDB using the Client Key. In between Service Worker restarts, the Client Key is held in memory.
After the user logs out of Keeper, or after the inactivity logout timer expires, the vault is locked and the user must login again using their Master Password.
When users login to Keeper using Single Sign-On: After the signed SAML response is returned by the SSO identity provider, Keeper delivers the user a Device-Encrypted Data Key ("DEDK") to the user. The Data Key is decrypted with the Elliptic-Curve Device Private Key ("DPRIV"). The Data Key is then used to decrypt the ciphertext delivered by the Keeper cloud. The Data Key is never stored, and the user must authenticate with the SSO provider in order to retrieve the Device-Encrypted Data Key every login in order to decrypt their data.
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 in IndexedDB. The Elliptic Curve private key is stored in Chromium CryptoKey storage.
Domain-to-Record mapping is stored via URLs hashed with HMAC_SHA256 using the Client Key.
Keeper works with NCC Group and Cybertest to perform ongoing vulnerability testing of the browser extension platform, which includes source code level analysis.
KeeperFill requires certain permissions in the browser extension framework in order to provide basic functionality that is required by users. These permissions are only utilized to provide expected functionality, such as:
Matching stored vault credentials to the current web page
Interacting between the vault and the on-page form filling capabilities
Detecting login fields, payment card fields and other field types
Autofilling credentials into a website login page
Saving credentials after login
Interacting with FIDO2 WebAuthn for saving and filling passkeys
Working with HTTP Basic Auth website login schemes
The Keeper Security browser extension does not use these permissions to track or record your browsing history for any other purposes than to provide the aforementioned services. It's built on a zero-knowledge security model, which means that all encryption and decryption of your data happens locally on your device. Keeper's servers do not have access to your unencrypted data, nor do they store your browsing history.
The below permissions are declared by the KeeperFill extension manifest. These descriptions are also provided to platform app stores (Google, Apple, Microsoft) in the permission justification requirements.
This permission allows the user to right-click/control-click into a "context menu" and select a credential to be used for autofill. It also grants the ability to perform other actions like creating new records, logging out and launching the Keeper Web Vault Application.
This permission allows Keeper’s extension to detect the website which is open in the current tab and provide the most relevant credentials within the contents of the right-click/control-click "context menu". It also allows the user to open new tabs from the Keeper Web Vault Application by clicking on the "launch" button to open and autofill a website of choice. Lastly, it also enables the user to access the Keeper user guide, help content and other support materials.
The Keeper extension is using alarms for the idle logout timer. When logged in, the user will have an alarm set for them equal to their logout timer time (if they have one). When the user interacts with the browser or Keeper's application, the alarm is reset for that same amount of logout time.
The Keeper extension is using the idle permission for the logout timer when the computer goes to sleep and is brought back up. This permission tells the Keeper extension that the user woke their computer up, letting the extension perform a check against the idle logout timer time and the current time on the machine to determine if the user is logged in to their vault.
The storage API is used to store local settings on the extension. Keeper also uses the "clear" function for the user to be able to clear their local info stored on the extension.
This permission allows the extension to automatically update the Keeper Web Vault Application to the latest version, ensuring compatibility between extension and web vault.
This permission is used only for HTTP Basic Auth autofill of login/password on supported websites.
This permission is used to inject static content scripts into web pages, in order to detect fields and perform autofill functionality. The details of content script security are described below.
This permission is used to create web workers and perform processing on multiple threads instead of a single thread.
This permission is used only for HTTP Basic Auth autofill of login/password on supported websites.
This permission is used only for HTTP Basic Auth autofill of login/password on supported websites.
This permission is used in the MV2 version of Keeper, and only for HTTP Basic Auth autofill of login/password on supported sites. This is deprecated in MV3.
The Keeper Web Vault implements a strict Content Security Policy that restricts the origin of outbound requests and prevents all scripts from being executed, except those explicitly sourced from Keeper, including inline scripts and event-handling HTML attributes, reducing or eliminating most vectors for cross-site scripting attacks.
Access to the keeper domain names is restricted to HTTPS with TLS 1.3 and is enforced by HTTP Strict Transport Security. This prevents a wide array of packet sniffing, data modification, and man-in-the-middle attacks.
Within the Keeper Browser Extension, Keeper will not prompt users to login to their vault from within the page frame area. Login to the extension occurs within the Browser Extension toolbar area of the browser. Login to the vault on the web browser will always occur either on the keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca or govcloud.keepersecurity.us domain, or from the Keeper browser extension toolbar which exists outside of the content page.
The Keeper Browser extension on Chrome, Firefox, Edge and Safari places an iFrame into the login forms of a web page to ensure that no malicious website has access to injected content. Record content injected into iFrames is also limited to the vault records stored in the user's vault which match the domain of the target website. Keeper will not offer Autofill of login or password data unless the website domain matches the website domain field of the Keeper vault record.
The Internet Explorer Extension uses a separate native application window for logging in and accessing records. These separate windows are not subject to XSS attacks because they are not accessible from the browser. This allows the Extension in Internet Explorer to provide a login window from inside the page. The extension will not show records unless the records match the website address root domain.
3rd party browser extensions may have elevated permissions in web browsers and can access information within the page. Therefore, it is recommended that Keeper administrators prevent users from installing 3rd party browser extensions from the browser's respective app store.
Background Scripts are run by the Browser Extension framework, which work with local storage and CryptoKey storage.
Web Page scripts are added to pages and perform detection of fields.
iFrame-injected documents process the Keeper user interface and user-initiated fill actions.
Context menu (right-click) scripts are built from the Chrome extension background scripts.
Browser Action (Toolbar) filling communicates with background scripts and manages the UI toolbar menu.
Content scripts communicate with Background scripts via Chrome messaging APIs (chrome.tabs.sendMessage).
The Browser Extension and Web Vault communicate with each other via native Port messaging on chromium browsers and window.postMessage on Firefox. Messages are encrypted with Elliptic Curve transmission keys.
Background scripts communicate with Keeper's Zero-Knowledge backend API.
The Keeper Browser Extension (KeeperFill) provides customers with the ability to fill and save credentials from their vault into a target website login page.
The Autofill feature protects against XSS attacks using many techniques and advanced functionality including but not limited to the following:
An iFrame is added into the login forms of a web page to ensure that no malicious website has access to injected content.
Domain matching is performed to ensure that only matching records are available for Autofill. Keeper will not offer to fill passwords unless there is a root domain match.
Customers may also enforce strict subdomain matching in role enforcement policies to restrict available logins based on exact subdomain match.
Keeper will not autofill passwords on any non-secure (http://) website, without explicit forced consent by the user or the Keeper Admin.
Keeper regularly performs 3rd party Autofill-specific penetration testing with Cybersecurity firms including NCC Group and Cybertest.
Keeper Compliance Reports adheres to Keeper's Zero-Knowledge encryption model. From an encryption standpoint, here's how it works. When the Enterprise end-user logs into their vault, the Type, Title and URL fields are encrypted with the Elliptic Curve Enterprise Public Key. This data, we call the "Audit Data", is encrypted locally on the user's device and stored in the Keeper cloud. The Audit Data is continuously updated by the end-user devices over time.
The Keeper Administrator logs into the Admin Console using either a Master Password or Single Sign On. After a successful login, the Admin decrypts what we call the AES 256 Enterprise Tree Key and then decrypts the Elliptic Curve Enterprise Private Key. If the Administrator has permissions to run Compliance Reports, they can run a report over any user within the node that they have been granted permissions.
The encrypted audit data is delivered to the Admin Console and the Admin is able to decrypt audit data locally on their device using the Elliptic Curve Enterprise Private Key. The report contents are then displayed locally on the user interface and available for export into CSV, JSON or PDF format. Only the designated Keeper administrator can retrieve and decrypt the compliance report data for the nodes that they have been granted admin rights over.
Learn More about Compliance Reports.
| Patent No | Abstract |
|---|---|
System and method for providing secure cloud based single sign-on connections using a security service provider having zero-knowledge architecture. | |
System and method for a single sign on connection in a zero-knowledge vault architecture. | |
A method of detecting the existence of a breached password in a zero-knowledge vault without disclosing any identifiable information about the password to the service provider or any outside party. | |
System and method for chat messaging in a zero-knowledge vault architecture. | |
Method and apparatus for protecting account numbers and passwords. | |
Apparatus for selecting and displaying a file associated with a current geographic location. | |
Method for facilitating quick logins from a mobile computing device for autofilling login credentials into websites and applications. | |
User-defined identity verification system. |
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 researchers and believe that an ongoing relationship with the cybersecurity 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 good-faith 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 security@keepersecurity.com 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 security@keepersecurity.com 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].
Keeper performs 3rd party penetration and vulnerability testing with experts including NCC Group, Cybertest and independent security researchers against all of our products and systems. Report summaries are provided to Enterprise customers on request.
A: NO. We are Zero Knowledge and cannot decrypt customer data.
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. This key then unwraps the ciphertext to extract the Data Key which then unwraps the folder keys, record keys and record data.
Keeper uses 1,000,000 (1 million) PBKDF2 iterations.
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.
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. Once 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.
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.
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.
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.
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 Recovery Phrase method) is by storing a second copy of the user's data key that is encrypted with a 256-bit AES key generated from the user's 24-word recovery phrase. To complete a vault recovery, the user is required to (1) enter an email verification code, (2) pass the Two-Factor Authentication step (if enabled on the account) and (3) enter the recovery phrase locally on the device to decrypt the data key, which then allows the user to reset the Master Password. In addition to enabling Account Recovery, we recommend turning on Keeper's Two-Factor Authentication feature from the 'Settings' screen. 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.
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.
On your first device, a 256-bit AES "Data Key" is generated unique to each user. For consumers and for user who login with a master password, the master password you selected is used to derive a key with 1,000,000 rounds of PBKDF2 that wraps and unwraps your Data Key locally.
On the Keeper cloud, we store the encrypted version of this Data Key. When you login on a new device and type in the master password, a key is derived locally, then hashed, and used for authentication with the cloud. After authentication is successful (and after you pass the device verification and 2FA step), we send the encrypted ciphertext to your device, and then you decrypt the ciphertext locally on your device using the master-password-derived key. This produces the Data Key which is then used to decrypt the vault locally.
If you change your master password, the new master-password-derived key will wrap your AES-256 Data Key. The resulting encrypted key is again stored in our cloud. The master password never leaves your device.
Users who login with SSO follow a different process as described above in the SSO cloud section.
This section details the strength of Keeper's AES-256 encryption method (using Master Password authentication) versus the strength of ECC-256 (when using SSO authentication via Keeper SSO Connect).
For symmetric encryption, Keeper uses AES-256. The advanced encryption standard (AES) is assumed to be a pseudorandom permutation. By the PRP/PRF switching lemma this assumes key recovery requires brute force key enumeration.
Assume that:
1 ns/candidate key (this assumes 3 cycles/key and a 3GhZ CPU
Attacker has 1 millions CPUs operating in parallel
AES-128 = 2^128 keys / (1 ns/key * 10^6) = 2^108 ns >= 10^16 years
AES-256 = 2^256 keys / (1 ns/key * 10^6) = 2^108 ns >= 10^54 years
AES-256 key enumeration is considerably longer than AES-128, and both require more computing resources than exist presently and more than 1 billion years of compute time. Key enumeration for either algorithm are considered improbable avenues of attack given the best known attacks against AES.
ECC-256 with AES-256
ECC-256 gives only 128b of key enumeration given the best known attacks against these elliptic curves. This is half the strength of AES-128. It is true that key enumeration attacks against ECC-256 are likely easier than attacking AES-256. However, the performance difference between AES-256 vs AES-128 is negligible, but the performance difference between ECC-256 and ECC-512 is noticeable and some libraries do not support 512b versions of elliptic curves, unfortunately.
ECC-512 Usage
As is noted above key enumeration attacks against AES-128 and AES-256 are impractical. But since the performance penalty is negligible and AES-256 is supported in all development libraries, the implementation is easy and standardized. Using ECC-512 is challenging since it's not universally supported and has noticeable performance penalties.
It's worth noting that the Bitcoin blockchain uses ECC-256. This creates a de facto 300 billion dollar bounty on the strength of 256b elliptic curves.
Strength of an AES key derived by PBKDF2 applied to a Master Password
No matter the size of AES key (128b, 192b, or 256b), if the AES key is derived from a password and key derivation function, the strength of the key is very likely to be bounded by the strength of the password combined with the complexity if the key derivation function.
Keeper uses PBKDF2 (NIST SP 800-132) with 1 million iterations.
The derived key will have strength equal to the (entropy of the password) plus log2(iterations) up to a maximum of 256 for AES-256.
For 100,000 iterations: log2(10^5) = 16.6
For 1,000,000 iterations: log2(10^6) = 19.9
An empirical study indicates that the average password used by humans is 40.5b of entropy. This implies that an AES key derived from an average strength password would be:
For 100k iterations: 40.5+16.6 = 57.1b of entropy.
For 1,000,000 iterations: 40.5+19.6 = 60.1b of entropy.
In comparison, a randomly generated ECC-256 key has 128b of entropy.
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 If you have any additional questions or documentation requests, please email security@keepersecurity.com.
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 security@keepersecurity.com 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 security@keepersecurity.com 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].