Paranoid™ Zero Knowledge Encryption for Passwords

Share KeePass Passwords with your Team of multiple users

Enable client-side encryption right at the device level for Pleasant Password Server. 

Password Server provides End-To-End Encryption (E2EE) which allows secure password sharing with other users.

Users' passwords are encrypted on the client machine, remain encrypted in transit, and on the server and database. Decryption requires the unique user key, available only to the user, inaccessible to the server.

Even the server itself does not have the knowledge or ability to decrypt these keys, and so cannot access the user's passwords.

In version 8, each user has the ability to enable encryption to password entries. When encrypted, an individually encrypted copy is generated for each user that should have access to the password.

Concepts: Zero Knowledge Architecture, Zero Knowledge Server, Zero Knowledge Database, Zero Knowledge Passwords

Applies to: 

• Versions 8.0 or higher (Enterprise+SSO Edition)
• Password Server, and Web client app
• In the future it is expected: all client apps

 Have Questions?  Contact Us!

Paranoid™ Zero Knowledge Encryption for Passwords

Password Server has implemented End-To-End Encryption from client to other shared clients.

Implemented with the following specifications:

• AES256-GCM
• RSA 2048-bit Asymmetric Encryption
• Salt, PBKDF2-HMAC SHA256 with 100,000 iterations

Enable Zero Knowledge encryption:

• Navigate to the Web Application:
  • Settings > Encryption > Allow Client-Based Encryption Option

Once enabled, this setting can not be disabled for this database, at this time. So, first make a backup of your data.

The Zero Knowledge Concept

The Zero-Knowledge Encryption in Pleasant Password Server is accomplished with client-side encryption so that it is the client application that is encrypting and decrypting the secrets instead of the server encryption/decryption. This means the server does not generate the secrets, cannot decrypt them, and cannot see them or access them.

Throughout this process, the server can facilitate the storage and retrieval of secrets without ever knowing what those secrets are. This is the "zero knowledge" aspect of the system.

Zero Knowledge Security Benefits

Has the following benefits:

• Protects secrets from Hosting / Cloud Partners
• Protects secrets from Internal threat actors
• Provides another layer of encryption
  • on the database & server
  • in transit from the device

The Zero Knowledge Workflow

Here is an overview of the process and how this works in Password Server:

1. Key Generation:

   • Initially the client app generates a pair of asymmetric encryption keys for a user - a public key and a private key.
   • The public key is used to encrypt the data and can be safely distributed for other users to encrypt data and share with this user.
   • The private key is kept secret and is used to decrypt password data.

2. Key Storage:

   • The user's private key gets securely encrypted and wrapped by the client, transmitted to the server in encrypted format, and stored in the database.
   • Later this can be retrieved and provided back to the user's client app.

3. Encryption of Secrets:

   • The client app encrypts the user's secrets using their public key.
   • This process transforms the secrets into a form that can only be understood if decrypted by the private key.

4. Transmission of Secrets:

   • The encrypted secrets are then transmitted to the server. Since the server or database do not have the private key, they cannot decrypt and access the secrets.

5. Storage of Secrets:

   • The server stores the encrypted secrets in its database.
   • Even if the database is compromised, the secrets remain safe because they are encrypted.

6. Authentication:

   • When the user wants to access their secrets, they first authenticate themselves as usual to the server, perhaps using 2FA if required.
   • The server verifies the user using regular authentication methods (e.g. using either local username/password, LDAP, or SAML SSO).
   • For these initial steps the server does not have or need to use the user's private key.

7. Decryption:

   • Once authenticated, the server sends the securely encrypted and wrapped private key back to the user.
   • The client app can then gain access to the private key by unwrapping it and decrypting it using the information provided by the user (encryption password or secret key).

This is a simplified explanation. The implementation is complex and involves additional steps and considerations to ensure security. 

Other Processes:

Beyond the basic overall explanation, there are some additional aspects of complexity to the implementation, with features such as:

• Symmetric Encryption: Another layer of symmetric encryption of the passwords (in addition to the asymmetric encryption),

• Individual Copy of Encryption Keys: Individual copies of an the Encrypted keys to the passwords are stored for each of the users that have access,

• Corporate Keys: Users with Administrate Users permission are delegated access to a Corporate Key when resetting other user's passwords, to facilitate resetting all user passwords,

• Active Directory Integration: When a user or role is modified in Active Directory and synchronized into Password Server, the changes are either processed automatically, or explicitly approved by an admin user.

Features

• Share Secrets Securely with other users
• Passwordless Sign-In (with SAML SSO)
• Encryption Keys
• Corporate Key Architecture
• Authentication Methods:
  • Secret Keys
    
  • User Encryption Passwords
    
  • Secret Keys or Encryption Passwords
    
• Password Resets
  • Admin - with Corporate Keys
  • User - Self-Serve Reset
• Active Directory / LDAP Integration
• New Device Easy-Transfer - of Secret Keys
• Client logging to server
• Secure Shared Web Worker Technology - web client support
• Military Grade Encryption: AES256-GCM, RSA 2048-bit Asymmetric

User Encryption Keys

Each user receives their own secret encrypted access based on their own Secret Key or Encryption Password.

These keys are used to safely encrypt and decrypt their data.

Secret Keys 

Secret keys are an option instead of using an encryption password.

Conveniently the user's Secret Keys can be securely stored on the user's devices, with an easy-transfer to subsequent devices. 

Encryption Security Methods:

• Secret Keys,
• User Encryption Password,
• Or both

Encrypting an Entry:

Entries can each be encrypted one at a time (currently).

Once a user has encrypted an entry password, each user that has access will get their own copy of the password, based on their individual encryption key. 

Sharing Secrets:

A secure copy of the encrypted data is provided to each user that has been granted access

Client App Safeguards:

Incompatible requests are securely blocked from accessing the E2EE encrypted values: other client apps, client types, older client versions, and other API requests 

Go Passwordless!

Passwordless Encryption Method

At this time this layer of encryption is enabled via General Systems, allowing the administrative user to decide which workflows they wish to enable

• User Secret Keys - which can be stored on any the user's device(s)

In this method, 1 user will have 1 Secret Key across devices.

Alternatively, you may choose to base encryption on: 

• Encryption Passwords, or

• Secret Keys & Encryption Passwords (both methods)

Device Level Encryption

Each web application client will encrypt/decrypt using the user's encryption keys, which are based on the method (above) chosen by the administrator.

Zero Knowledge Passwords

Secret fields which are encrypted with this method are visibly indicated with a secure shield and include:

• Passwords, TOTP Secrets

Expect additional fields in the future....

Process FAQ's:

Question: In what form is encrypted data stored in Password Server?

Answer: There is various encrypted data stored as encryption keys, encrypted with the following specs:

1. User Keys - asymmetric encryption

   • RSA 2048-bit Asymmetric Encryption
   • AES256-GCM
   • Salt, PBKDF2-HMAC SHA256 with 100,000 iterations

2. Password Keys - asymmetric + symmetric encryption

   • The entry passwords are also stored with an additional layer of symmetric key encryption, as symmetric keys.

Question: What agent is responsible for decrypting the data when it is displayed in the solution? Password Server or Client application?

Answer: All encryption is done on the client app. Currently, Zero Knowledge encryption is only available in the web client app. These encrypted passwords will not be visible in KeePass, mobile, or other client apps.

Question: What factor does the password server use to encrypt the data? The user password?

Answer: There are 2 new options provided:

• encryption password,
• secret key

These are uniquely generated and are used to generate public and private encryption keys for the user:
- The public key is used to encrypt data
- The private key is used to decrypt data

The secret key option is a key securely stored onto your device, which facilitates passwordless access which is especially useful for Single Sign-On type of convenience.

Question: How does access to encrypted data by other users work with Zero Knowledge Encryption?

Answer: There is some complexity but basically a copy of the password is generated using the user's own public encryption key, such that only they can have access, and no one else.

Question: How is it ensured that the data can be decrypted even after a password change?

Answer: When the password is changed, new copies of keys to access the password are generated for each of the users that should have access.

When a password is changed, a new copy of the key to the password is generated for each user that has access to the password. The copy is generated using each user's public key, so that the user can still decrypt it and access it (using their private key).

There is some additional complexity to this behind the scenes.

Question: Is the solution really "Zero Knowledge"? Especially if there is an automatic mechanism that enables access without further user input?

Answer: Yes, the Server and Database have Zero Knowledge of the password data: no visibility or possibility to see this data, and never have access to the data.

The data is encrypted when reaching the server, while stored in the database, and remains encrypted throughout transmission to/from the client.

So, they do not have access to the unwrapped unencrypted private keys needed to decrypt the data.

There are numerous things needed to decrypt, all of which the server/database do not have:

• unencrypted private keys, the user information, and the decryption processes themselves.

An attacker would have to breach the security on a client device, compromise this process to gain access to the user's private key, authentication, and possibly 2FA factors.

So, this accomplishes our goal of ensuring that even if a server or database is compromised, it will not provide access to all user passwords.

This provides an extremely high level of security for our users.

Question: How is it ensured that the user-specific factor is not transmitted to the server?

Answer: The client merely uses the user-specific data only to either generate or retrieve the decryption key. And so, there is no necessity, method, or possibility to transmit this information on to the server.

With the client application's encryption/decryption process there is also no need to store these initial values used to generate the key. Instead, the values unlock the mathematics of the encryption processes required.

Since the user information used in this process is not stored, then there is no possibility of a breach. Also, if it is lost there is also no ability to recover it. Instead, the user's password would need to be reset.

Question: How is the data and the encryption keys transferred between server and client?

Answer: The private key gets encrypted and wrapped by the client, and then transmitted to the server, such that it can only be decrypted by the user with the user-specific data (password or secret key).

The application data is encrypted similarly and transmitted to the client app.
The client app decrypts the data and displays it.

There is additional complexity to this. This is a simplified explanation.

Question: Is the data itself encrypted with the user-specific encryption factor or is another key used that can be decrypted by the user-specific encryption factor and can therefore be used to access the data?

Answer: Yes, there are multiple user-specific factors used in the encryption process, but there is no other key that can be used to decrypt or access it, other than the selected factor(s): encryption password or secret key.