To make security even tighter, pepper hashes can be used along with a user specific salt to encrypt passwords.
Here is how it works:
pepper values are NOT stored in the database. It is crucial that these values are stored separately from salt values. Proposal: store these values in the plugin settings in the .kuzzlerc file
This new property should be an array of 0..n hashes. These hashes do not need to be as long as the salt value, since even a single byte appended is enough to get a completely different hash in the end (see Avalanche effect )
Some kind of CLI tool should be added to the plugin, generating n pepper values, helping administrators to set up this new property. It is essential to have randomly generated hashes and not a preset algorithm (like appending one of the 26 letters of the alphabet, randomly), since part of the added security comes from the necessity for an attacker to somehow retrieve these hashes in order to attempt a bruteforce in case of a DB-leak
When pepper values are provided in the settings:
Upon encrypting a new password, a pepper value should be taken randomly from the configured set of hashes, and used along with the salt to encrypt and store the password. The information about what pepper value was used must NOT be stored (not in a cache, not in the database, nowhere). The purpose of this is to make it impossible for attackers to bruteforce a password without pepper values and, even if these hashes are compromised, bruteforcing against n pepper + 1 salt makes it a considerably harder and slower task
When verifying a password entry, it should be tested using all pepper values, until one is found to match its corresponding encrypted version. This forces Kuzzle to perform n checks before denying access if an erroneous password is provided, effectively slowing down the login process and making it harder to bruteforce through the API
The pepper property of a user document must be set to true if a pepper value was used to encrypt the password (since #49, all new user documents contain a pepper property, set to false)
The plugin must use the pepper property stored in user documents to determinate how a password must be verified, allowing databases to contain encrypted password both with and without pepper values (this is to allow adding pepper values on existing databases)
To make security even tighter, pepper hashes can be used along with a user specific salt to encrypt passwords.
Here is how it works:
.kuzzlercfilepepperproperty of a user document must be set totrueif a pepper value was used to encrypt the password (since #49, all new user documents contain apepperproperty, set tofalse)pepperproperty stored in user documents to determinate how a password must be verified, allowing databases to contain encrypted password both with and without pepper values (this is to allow adding pepper values on existing databases)As per https://github.com/kuzzleio/kuzzle-plugin-auth-passport-local/pull/49, encrypting passwords are now made on background threads, so having a slower password matching process should not have any impact on the event loop.
More information about pepper values here: https://en.wikipedia.org/wiki/Pepper_(cryptography)