Addendum B - User Filtering
User Filtering
Keeper Bridge is designed to invite users to your Keeper group which are found in the Distinguished Name (DN) Path and User Filter defined. The DN Path can be set to any location within the Directory. It is not necessary to create a Keeper-specific Directory group.
Since each Directory Service implementation may differ and each implementation is expected to have varying needs, the User Filter is fully customizable. This allows you complete flexibility to define the portion of the Directory to invite your Keeper users.
Keeper Bridge creates a default filter based on the DN Path defined. This default filter will function for any site with the following assumptions:
1. A person or group in the Directory is defined by objectClass. (Required)
2. Keeper Bridge will search the DN Path and all nested groups for all person and group objects
3. A user account should always be Invited unless it has been deleted or moved out of the DN Path specified.
4. Disabled and accounts will be invited, unless Disable Accounts is Checked on the Options form.
If items 2 through 4 above are not desired, a custom filter can be created. A skilled Directory Services Administrator may be required to determine what a custom filter should include.
Default Filter
The default filter is created based on the DN Path entered.
Example default filter:
(&(objectclass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1,DC=testdomain, DC=com))
The default filter has two filter conditions:
(objectclass=person) - Restricts object returned to a type of “person”. This filter condition is required for Keeper Bridge to distinguish between people, groups and other types ofobjects within the Directory.
(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com) - The OID (1.2.840.113556.1.4.1941) allows queries for users to be done in the Subtree starting in the DN path specified. Removing the OID restricts the users found to just the DN path specified and users in nested groups would not be returned.
Custom User Filter Examples
Example filtering for users only in the DN Path. Users which are in nested groups will not be invited (bold is the delta from default filter):
(&(objectclass=person)(memberOf:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Example filtering out disabled accounts (bold is the delta from default filter):
(&(objectclass=person) (!userAccountControl:1.2.840.113556.1.4.803:=2)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Example filtering out accounts that have been “Locked Out” (bold is the delta from default filter):
(&(objectclass=person) (!userAccountControl:1.2.840.113556.1.4.804:=18)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Example filtering out disabled accounts and accounts that have been “Locked Out” (bold is the delta from default filter):
(&(objectclass=person)(!userAccountControl:1.2.840.113556.1.4.803:=2)(!userAccountCotrol:1.2.840.113556.1.4.804:=18)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Example of filtering for users only in a geographic location (bold is the delta from default filter):
(&(objectclass=person) (physicalDeliveryOfficeName=Chicago)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Example of filtering out a specific user (bold is the delta from default filter):
(&(objectclass=person) (!sAMAccountName=jjones)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))
Keeper
Customers who purchase Keeper are provided an extra layer of control over their users and devices. Keeper administrators are provided access to an administrative console.The console allows the administrator to manage the users who belong to the organization, control the sharing of records and which devices are permitted to sync.
Keeper Administrative Console
http://keepersecurity.com/console
Delegated Admin & Policies
Keeper supports delegated administration for companies having multiple divisions or work groups. Role-based permissions control which users have access to shared credentials and files. Active Directory can deploy users into subgroups with roles defined by the enterprise or controlled via Keeper’s Admin Console.
Subgroups are defined by the group Admin. Within a subgroup, admin users are defined. Admins can be created in a subgroup via the Admin Console. For example, different divisions of a large enterprise customer can be separated into subgroups. Permissions do not cross subgroups.
Administrators of a Keeper subgroup create Roles via the Admin Console or automatically through AD group filters via the Keeper Bridge.
Roles & Shared Folders
A Role is a set of users that are associated with a set of Shared Folders. Roles are assigned restrictive permissions that limit their ability to edit and share records within a Shared Folder.
The implementation of role-based permissions allow the Delegated Admin of the Keeper group to assign restrictive permissions at a role or user level. Shared Folders are assigned both roles and users for the greatest flexibility and control. Encryption and decryption of records is managed in a zero-knowledge environment through the multi-layered distribution and synchronization of record decryption keys. Mobile and Desktop applications provide users with a seamless and easy-to-use system for accessing and building shared content, if permitted.
A Shared Folder can be created by anyone in the subgroup. A Shared Folder is assigned Roles or individual users. If the subgroup restricts sharing outside of the subgroup, only Roles and Users from that subgroup can be added. From the Shared Folder, the admin of that folder assigns which Roles/Users have the ability to manage the Shared Folder.
Technical Architecture
KSI does not have access to a customer’s master password nor does KSI have access to the records stored in the Keeper vault. KSI cannot remotely access a customer’s device nor can it decrypt the customer’s vault. The only information that Keeper Security has access to is a user’s email address, device type and subscription plan details (e.g. Keeper Unlimited). If a user’s device is lost or stolen, KSI can assist in accessing an encrypted backup file to restore the user’s vault once they have replaced their device.
KSI does not have access to a customer’s master password nor does KSI have access to the records stored in the Keeper vault. KSI cannot remotely access a customer’s device nor can it decrypt the customer’s vault. The only information that Keeper Security has access to is a user’s email address, device type and subscription plan details (e.g. Keeper Unlimited). If a user’s device is lost or stolen, KSI can assist in accessing an encrypted backup file to restore the user’s vault once they have replaced their device.
Information that is stored and accessed in Keeper is only accessible by the customer because it is instantly encrypted and decrypted on-the-fly on the device that is being used - even when using the Keeper Web App. The method of encryption that Keeper uses is a well-known, trusted algorithm called AES (Advanced Encryption Standard) with a 256-bit key length. Per the Committee on National Security Systems publication CNSSP-15, AES with 256-bit key-length is sufficiently secure to encrypt classified data up to TOP SECRET classification for the U.S. Government. In theory, it would take a 10.51 petaflop supercomputer approximately 3.31 x 1056 years to brute-force a 256-bit AES encrypted message.
Τα κλειδιά κρυπτογράφησης που χρησιμοποιούνται για την κρυπτογράφηση και αποκρυπτογράφηση αρχείων πελατών δεν αποθηκεύονται ούτε μεταδίδονται στο Cloud Security Vault του Keeper. Ωστόσο, για την δυνατότητα συγχρονισμού πολλαπλών συσκευών, μια κρυπτογραφημένη έκδοση αυτού του κλειδιού κρυπτογράφησης αποθηκεύεται στο Cloud Security Vault και παρέχεται στις συσκευές του λογαριασμού του χρήστη. Αυτό το κρυπτογραφημένο κλειδί κρυπτογράφησης μπορεί να αποκρυπτογραφηθεί μόνο στη συσκευή για περαιτέρω χρήση ως κλειδί κρυπτογράφησης δεδομένων.
Data Security
Client Encryption
Data is encrypted and decrypted on the user’s device, not on the Cloud Security Vault. We call this “Client Encryption” because the client (i.g. iPhone, Android Device, Web App, etc.) is doing all of the encryption work. The Cloud Security Vault stores a raw binary which is essentially useless to an intruder. Even if the data is captured when it’s transmitted between the client device and Cloud Security Vault, it cannot be decrypted or utilized to attack or compromise the user’s private data.
Data At Rest
Keeper uses PBKDF2 with HMAC-SHA256 to convert a password to a 256-bit encryption key with a minimum of 1,000 rounds.
The key generated from the Master Password isn’t used directly to encrypt user data, but is instead used to encrypt another key (the “Data Key”). The Data Key is used for encrypting data and other keys, such as the RSA private key.
Any key that is not generated directly from the user’s Master Password is generated by a cryptographically secure random number generator on the user’s device. For example, both the data key and the RSA key pair are generated on the device. Because the keys are generated on the device (not on Keeper’s Cloud Security Vault), we have no visibility into the user’s keys.
All secret keys that must be stored (such as each user’s RSA private key and the Data Key), are all encrypted prior to storage or transmission. The user’s Master Password is required to decrypt any keys. Since Keeper’s Cloud Security Vault does NOT have access to the user’s Master Password, we cannot decrypt any of your keys or data.
Data In Transit
To prevent unauthorized vault access, Keeper’s Cloud Security Vault must authenticate each user when transmitting data. Authentication is performed by comparing a PBKDF2-generated hash of the Master Password. The user’s device uses PBKDF2 to generate the hash from the Master Password and the server compares the hash to a stored hash.
By using the PBKDF2 hash instead of the Master Password itself, the Cloud Security Vault authenticates the user without requiring the Master Password. PBKDF2 is also used for generating encryption data keys, but the authentication hash is not used for data encryption.
KSI supports 256-bit and 128-bit SSL to encrypt all data transport between the client application and KSI’s cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns.
KSI deploys SSL/TLS certificates signed by Digicert using the SHA2 algorithm, the most secure signature algorithm currently offered by commercial certificate authorities. SHA2 is significantly more secure than the more widely used SHA1, which could be exploited due to mathematical weakness identified in the algorithm. SHA2 helps protect against the issuance of counterfeit certificates that could be used by an attacker to impersonate a website.
KSI also supports Certificate Transparency (CT), a new initiative by Google to create a publicly auditable record of certificates signed by certificate authorities. CT helps guard against issuance of certificates by unauthorized entities. CT is currently supported in the latest versions of the Chrome web browser. More information about Certificate Transparency can be found at: http://www.certificate-transparency.org/
KSI utilizes Transport Layer Security (TLS) (versions 1.0, 1.1, and 1.2) to securely transfer encrypted customer data between the client and the Keeper servers. KSI also supports Perfect Forward Secrecy (PFS) key exchanges using Diffie-Hellman (DHE) enabled cipher-suites.
Two-Factor Authentication
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.
Keeper uses something you know (your password) and something you have (the phone in your possession) to provide users extra security in the event 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.
When using the Google Authenticator 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.
Sharing Of Records
Each user has a 2048-bit RSA key pair that is used for sharing. Shared vault records are encrypted with the recipient’s public key. The recipient decrypts the record with their private key. This allows a user to share records only with the intended recipient, since only the recipient is able to decrypt it.
Product Support
If you have any questions please contact Keeper Support at: enterprise@keepersecurity.com
