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

Y Soft 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 YSoft SafeQ can be split into 3 categories based on the way they are encoded.

YSoft SafeQ user passwords

Passwords of internal YSoft SafeQ 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 YSoft SafeQ 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

Because the security of enhanced password protection relies on the secrecy of the encryption key, it is crucial to protect the key file from potential attackers. See the options below (can also be combined). In contrast, there is no way of decrypting the passwords without having access to the key, so a secure backup of the key should be considered.

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. YSoft SafeQ supports DPAPI for additional protection of the secret key. YSoft SafeQ 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 file protected by DPAPI can only be used on the machine that was used to protect the key. It is also not possible to recover the key (remove DPAPI protection) on a different machine.

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

When using DPAPI protection (described above), the key file must be distributed with DPAPI protection removed (as it is bound to a specific machine). After the distribution, DPAPI protection can be applied again. DPAPI cannot be utilized if the key file location is shared.

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 YSoft SafeQ 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 YSoft SafeQ, 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.

Term	Explanation
secret	Piece of data that is to be protected by encryption. Typically a password is in plain text.
key / encryption key / secret key	Uniquely generated key which is used for encryption (and decryption) of secrets (typically passwords). The key is a piece of secret data that is used to protect other secrets (passwords).
encryption	A process that protects secrets by changing the original plain text into other (encrypted) forms from which the original plain text cannot be easily deduced without knowing the encryption key. It can be understood as an application of enhanced protection.
decryption	A process that removes protection from secrets and provides original plain text. An administrator does not need to work with this form. YSoft SafeQ automatically decrypts secrets when needed.
encrypted password / encrypted secret / protected password	Data, typically a password, on which encryption was applied. In case the encryption was applied, we talk about an encrypted or protected password.
key file	A file in which the encryption key is stored.
secret name	An identifier of the secret. It is typically the name of the property holding the secret.
password protection tool	It is a command-line tool developed by Y Soft. The tool is used for example for the key generation and encryption of secrets.
enhanced password protection	The name of a feature YSoft SafeQ uses for enhanced protection of passwords.
hashing	One-way no-key cryptographic transformation of a variable-length input to a fixed-length output. In contrast to encryption, original input cannot be directly calculated, it can only be guessed.
obfuscation	Encryption that does not rely on a provided secret key (e.g. the key is part of the application instead). This means the result is not easily readable but could be decoded by anyone having access to the application (either by running it or extracting the decoding procedure).