Enhanced password protection is a feature for strong encryption of non-user secrets (e.g. passwords to a database (DB) or LDAP) in configuration files and a database. Those secrets can be recognized by the ENCSTR: prefix if encrypted.

Encryption of passwords in database and configuration files

Konica Minolta SafeQ stores highly sensitive data (e.g. passwords) in database or configuration files. Even though access to server storage is typically highly restricted, an additional encoding layer of protection might be desired to mitigate certain attacks.

The passwords in Dispatcher Paragon can be split into 3 categories based on the way they are encoded.

Dispatcher Paragon user passwords

Passwords of internal Dispatcher Paragon users are not encrypted but stored in a form of a cryptographic hash designed specifically for password storage (bcrypt by default). It is a one-way function that makes a calculation of the original passwords extremely time-consuming (for non-trivial passwords). Note that users' domain (LDAP) passwords are never stored.

Non-user passwords with enhanced password protection support

For most critical passwords, robust "enhanced encryption" (format ENCSTR:...) can be enabled to prevent reading or changing the password without having access to an encryption key unique for each server. One of the benefits is that read access to configuration files or DB content can be given also to less trusted individuals as the most sensitive data is protected by strong encryption. It also mitigates shoulder surfing (or camera recording) and decreases the impact in case of a data breach (if the key file is protected well, see the section below).

Because manual steps are needed to set up the encryption, the encryption is switched off by default and the passwords are stored in plain text. See Setup and Configuration of the Enhanced Password Protection for required steps for configuring the encryption mechanism. Some other details about the feature can be found below in this document. Currently, these passwords are supported (support of other passwords is planned):

• Passwords to connect to Management DB stored in the file safeq.properties and DBValidator.properties
• Passwords to connect to IMS DB stored in file application.properties
• Tenant DB passwords stored in Management DB
• Passwords to LDAP stored in Management DB
• Password to SMTP stored in Management DB
• Password to FTP/WebDAV scan server in Management DB

Connector's secret data

With enhanced password protection your connectors' sensitive data (e.g. tokens for accessing your storage or passwords) will be encrypted in the database and they will be visible in the Dispatcher Paragon Management Server only in encrypted form.
This applies to creating new connectors or editing old ones (changing descriptions is enough). Old connectors which are not modified after enabling enhanced password protection will be stored in the old obfuscation form.

Non-user passwords supporting only legacy encryption (obfuscation)

Non-user passwords that don't support enhanced password protection, use the legacy way of encryption (format code,...). It obfuscates the passwords so that they are not stored in plain text but because a hard-coded key is used for encoding, an advanced attacker might decode plain values. For this reason, it is recommended to handle the obfuscated secrets as if they only were in plain text (e.g. never send a configuration file with obfuscated passwords over an unsecured channel).

For backward compatibility, decoding of obfuscated passwords is also supported for passwords using enhanced password protection.

Protecting the key

Configuring file permissions

Only highly trusted individuals should have read access to the key file (on the path configured). In addition, write access to configuration files, binaries, and logs need to be limited to prevent active attacks. Tampered files might be used to leak encrypted passwords after they are decrypted by the system otherwise. The integrity of log files (and their configuration) needs to be ensured for audit purposes.

Storing the key file to an encrypted location

The key file can be stored in a location that is transparently encrypted on the system or hardware level. For example, EFS can be utilized to add an additional encryption layer on the filesystem level.

Using Data Protection API

Data Protection API (DPAPI) is a cryptographic tool available as a built-in component on supported Windows OS versions. DPAPI provides operating system-level data protection. DPAPI encrypts and decrypts custom data in a way that there is a cryptographic link between protected data and a given server. Dispatcher Paragon supports DPAPI for additional protection of the secret key. Dispatcher Paragon allows administrators to easily use the DPAPI protection and lock the secret key with a server on which the key is to be used. Flags used for DPAPI protect operation are CRYPTPROTECT_LOCAL_MACHINE, CRYPTPROTECT_UI_FORBIDDEN, and CRYPTPROTECT_AUDIT.

DPAPI protection is not enabled by default, it can be applied and removed via the password protection tool using the commands protectkeys and unprotectkeys.

For more information about DPAPI please visit this page: https://support.microsoft.com/en-us/help/309408/how-to-troubleshoot-the-data-protection-api-dpapi

Key management

Initial key generation

Before using enhanced password protection, a secret key needs to be generated (there is no default key). The preferred way to do that is by running the password protection tool with the command initkeys after the path to the key is set. The file is created automatically if it doesn't exist. Alternatively, 32 random bytes encoded in Base64 can be put as text into the file on the path.

Changing the encryption key

There might be a need to change the encryption key if there is suspicion of leakage or just as a preventive measure. The changekey command generates a new key and appends it to the key file. Any number of keys is supported (for many keys there might be performance issues though). When more keys are present, only the last one is used for encryption but all keys are used to attempt decryption of a previously encrypted secret. To make sure all secrets are encrypted with the newest key, they need to be re-encrypted (decrypted and encrypted again) manually. When this is done, old keys can be removed by the command deleteoldkeys.

Key backup

As there is no way of decrypting previously encrypted passwords without the correct key, a backup should be considered (if passwords themselves are not backed up in decrypted form). However, for security reasons, the key file should not be backed up together with encrypted passwords, since the passwords could be easily decrypted in case of leakage (so there would be no extra security). Keys should be backed up with DPAPI protection (see above) removed as the original machine might not be available for restoration. Note that you can create a key file containing a few keys so that the passwords can be easily decrypted no matter the key originally used to encrypt them (this could make the restore procedure easier).

Using enhanced password protection with Management cluster

Since nodes of a Management cluster share the same database with encrypted passwords, all nodes must have access to the same encryption key. This means the key file cannot be simply initialized on the nodes separately, there are basically two solutions:

• Use a shared location for key file storage, generate the key there, and configure this path on every node
• Generate the key on the first node, copy it, and distribute it manually on all other nodes

Technical details of the protection

Secrets are encrypted using the AES algorithm in CBC mode of operation and random IV. Encryption is non-deterministic by design so that the same secrets will result in different ciphertexts each time they are encrypted. The length of a secret is partially masked by PKCS5 padding. The ciphertext is then authenticated using the HMAC-SHA256 algorithm and truncated authentication tag concatenated to the output which is encoded to Base64 and prefixed with ENCSTR: afterward. HMAC uses an independent key - every key in the key file contains both encryption and authentication keys internally.

Role of secret names

The authentication tag is calculated not only from the ciphertext but also from the identifier of each secret (as additional authentication data), which is typically the name of the property holding the secret. The same value also needs to be passed when decrypting the secret because cryptographic integrity is verified before decryption. As encrypted secrets are transparently decrypted by Dispatcher Paragon utilizing the same key, this feature improves security by only allowing to decrypt secrets intended for a given purpose.

For example, if an internal attacker had access to the management interface and the SMTP server configured in Dispatcher Paragon, it would not be possible to steal the LDAP password by setting its encrypted form as an SMTP password.

Terminology table

The following table explains technical terms. In the text, there are sometimes different terms used for the same thing.