Recommended Security Settings

Administrative recommendations for Keeper Security policies and settings

Shared Security Model

At the foundation, Keeper is an encryption platform with policies and controls in place to protect customer data, within the constraints set by the Keeper administrator. In this shared security model, the customer is responsible for implementing recommended policies to ensure least privilege, break glass access, and the highest levels of data protection. This document outlines key recommendations and policies that will help you secure the data stored within the environment, while ensuring the best possible experience for your target users.

1. Create at least 2 Keeper Administrators

Keeper Administrators hold the encryption keys used to access the Admin Console, provision users, manage enforcement policies and perform day to day user administration.
The "Keeper Administrator" role should have at least two users in that role. We strongly recommend adding a secondary admin to this role in case one account is lost, the person leaves the organization or the. The Keeper support team cannot elevate a user to an administrative role or reset an administrator's Master Password, by design.

2. Ensure an Admin Exists Outside of SSO

Keeper SSO Connect Cloud provides customers with the ability to provision and authenticate users with their preferred SAML 2.0 identity provider.
While Keeper supports the ability for admins to login to the Keeper Admin Console with SSO, it is important that at least one Admin account is able to login to Keeper with a Master Password. This is because a situation could occur in which all admins rely on SSO, and there may be no admins to approve a new device. Or, the SSO provider could have an outage which then locks everyone out. We recommend creating an Admin "service account" which uses a strong Master Password, 2FA and (optionally) IP AllowListing to optimally lock down this account.
In the situation where all admins use SSO, and all admins are on new devices (unable to approve them) Keeper support will not be able to help recover. By design, Keeper is a zero knowledge platform and our support team has no ability to approve SSO-enabled devices, or recover Device-Encrypted Data Keys for users.

3. Enable Account Transfer Policy

Account Transfer provides a mechanism for a designated administrator to recover the contents of a user's vault, in case the employee suddenly leaves or is terminated. This is an optional feature that must be configured by the Keeper Administrator during the initial deployment phase of the Keeper rollout, because it requires specific steps to escrow the user's encryption keys.
For step by step details visit the Account Transfer Policy guide.
The Account Transfer policy is recommended if users are authenticating with a Master Password, and if the enterprise has concerns regarding the loss of specific user vaults.

4. Disable Account Recovery

As with any SaaS platform, account recovery provides end-users with a route to restore access to their account, if the primary authentication methods are lost or forgotten. In Keeper, by default the user has an ability to configure a Recovery Phrase - a simple, auto-generated set of 24 words that can be used to restore access to their Keeper Vault. The recovery phrase encrypts the user's Data Key using a key derivation similar to the Master Password method.
If you are deploying to users with a single sign-on product like Azure, account recovery may not be necessary or warranted, since authentication is delegated to your identity provider. Therefore, it is best to simply not have account recovery as an option, if this is acceptable to your users.
To disable account recovery, visit the Role > Enforcement Policies > Account Settings > select "Disable Recovery Phrase for account recovery".

5. Enforce a Strong Master Password

For users who login with a Master Password, the key to decrypt and encrypt the Data Key is derived from the user’s Master Password using the password-based key derivation function (PBKDF2), with 1,000,000 iterations by default. After the user types their Master Password, the key is derived locally and then unwraps the Data Key. After the Data Key is decrypted, it is used to unwrap the individual record keys and folder keys. The Record Key then decrypts each of the stored record contents locally.
Keeper implements several mitigations against unauthorized access, device verification, throttling and other protections in the Amazon AWS environment. Enforcing a strong Master Password complexity significantly reduces any risk of offline brute force attack on a user's encrypted vault.
The National Institute of Standards and Technology (NIST) provides password guidelines in: Special Publication 800-63B. The guidelines promote a balance between usability and security; Or in other words, passwords should be easy to remember but hard to guess. The NIST instruction recommends an eight character minimum but a higher value will ultimately result in a harder to guess/crack password. Keeper enforces at least 12 characters. We recommend increasing this to 16 or more.
Password complexity can be configured on a per role-basis. See the master password complexity enforcement setting in the guide.

6. Enforce the use of Two-Factor Authentication

Two-Factor Authentication (2FA), also commonly referred to as multi-factor authentication (MFA), adds an additional layer of security to access the vault. The first layer is something your users know; their Master Password or SSO. The second layer is something they have. It can be either their mobile device (SMS text or a TOTP application) or by using a hardware device such as YubiKey or Google Titan key.
While Keeper's cloud infrastructure implements several mitigations against brute force attack, adding a second means of authentication will makes it considerably more difficult for an attacker to gain access a user's vault. Using a role based enforcement can ensure all users of the enterprise are mandated to configure 2FA on their vault account. SSO-enabled users should ensure 2FA is configured with their IdP at a minimum. Keeper checks for a signed assertion from the identity provider during SSO authentication. For additional security, 2FA can be enabled on the Keeper side in addition to the IdP. To set up 2FA See the section in the guide: Two-factor Authentication

7. Configure IP Allowlisting

To prevent users from accessing their work vault outside of approved locations and networks, administrators should consider activating IP Address Allowlisting. This is a role-based enforcement setting that designated users can only access their vaults when their device is on an approved network.
Visit the section on IP Allowlisting for more information on configuring roles to include this feature.

8. Create Alerts

Keeper's Advanced Reporting System provides built-in Alerting capabilities that will notify users and Administrators for important events. As a best practice, we have created a list of recommended alerts that can be configured by the Keeper Administrator.

9. Prevent Installation of Untrusted Extensions

As a general security practice, we recommend that Enterprise customers limit the ability of end-users to install unapproved 3rd party browser extensions. Browser extensions with elevated permissions could have the ability to access any information within any website or browser-based application. Please refer to your device management software to ensure that Keeper is allowed, and unapproved extensions are blocked or removed.