Hash passwords in demo server configuration
In current demo server implementation, passwords are stored in clear text for the username security policy. This could be accepted for a demonstration but is not a good practice for an operational system.
The objective of this issue is to replace clear password by a Hash (sha256) with a dynamic suffix as a salt. The configuration file stores the hash and the dynamic salt.
The chosen hashing method is PBDKF2 (as described in RFC 8018) with an iteration count sufficiently high to protect the passwords efficiently.
To avoid the introduction of a timing attack against usernames by a remote attacker through the ActivateUserRequest
, all user authentications must take the same time.
To do so:
- unknown users must still have their password hashed (even if empty) so that they cannot be discriminated,
- all passwords must be hashed with the same iteration count so that user with password with fewer iteration count cannot be identified.
The second point implies that the current implementation (!905 (merged) version 4, 0032a6ac) must be changed so that the iteration count for hashes is the same for all user entries.