4.3. Initialisation of eurephia
4.3.1. Password parameters
------------------------------------------------------------------------------
eurephia :: PASSWORD PARAMETERS
------------------------------------------------------------------------------
Salt length for password hashes [32]
Salt length defines an important parameter in password hashing algorithms. It defines how many bytes of random data which will be used as a salt to a given password to make sure the resulting hash is as unique as possible, even if more users use the same password. It does not make sense to make it too long, as the salt will be readable in clear-text. The salt does not need to be too long. The default value in newer glibc versions is 16 bytes, while eurephia uses 32 bytes as default.
** Preparing for SHA512 performance benchmark.
Aiming for minimum hashing calculation time: 95ms
Aiming for maximum hashing calculation time: 200ms
Benchmarking .................................................................... Done
Suggested minimum rounds: 33000 (takes 95ms)
Suggested maximum rounds: 63000 (takes 196ms)
Minimum hashing rounds: [33000]
Maximum hashing rounds: [63000]
==============================================================================
After the salt length has been defined, eurephia will try to benchmark how efficiently your server computes SHA512 hashes. For a password hash to be secure and to make it difficult to crack, it is important that the CPU spend some time calculating a hash. On the other hand, a password hash should not take too long to calculate as that will take resources from other processes on your server and it will slow down establishing the OpenVPN connection. By default, this benchmark should take minimum 95ms to calculate a hash, and not longer than 200ms. These thresholds can be tuned by yourself with the --hash-threshold-min and --hash-threshold-max options to eurephia_init. On the test machine as shown above, it was able to calculate 33.000 hashes within 95ms and 63.000 hashes within 196ms.
Beware that CPU scaling utilities like cpuspeed and cpufreq will have a noticeable effect on this benchmark. It is recommended that you try to have the CPU frequency as close to the normal situation as possible, to get numbers which will be more relevant. If you are upgrading the system with a new CPU, a new benchmark is recommended.
It might be tempting to set high hashing round numbers. But beware that if the CPU will spend too much time calculating password hashes when clients connect, they might experience timeouts. This is especially important if you have many simultaneous users.
While having a reasonable amount of hashing rounds is important, having a good distance between the minimum hashing rounds and maximum hashing rounds is just as important in order to increase the difficulty brute-forcing the password hash.
If your hardware is able to handle minimum 5.000 rounds within a reasonable time, that is the absolutely recommended minimum value. The hard minimum limit in eurephia is 1.000 rounds. The hard maximum limit is 999.999.999.
4.3.1.1. Why these minimum/maximum values?
The password hashing algorithm in eurephia is trying to be a little bit unpredictable to brute-force attack situations on the password hashes. When a new password is set, eurephia will pick a random number between the minimum and maximum hashing rounds values. This value is encoded into the password hash and scrambled based on the password itself.
If an attacker get access to the password table and starts a brute-force attack on the hashes, the password hashing rounds number in the hash will also be deciphered wrong and the computed password hash will be wrong as well. The hashing round number is scrambled with a four byte value, so for each password there will be up to 232 possible hashing round values to try on each password.
An attacker who gained access to your password hashes will most probably also have access to the minimum and maximum values used for the hashing. This means that several of the 232 possible hashing round values might be outside the minimum and maximum scope. So having a wider spread between minimum and maximum will be an advantage, as that will give more hashing rounds which needs to be tested.
