From: Nicolas CARPi Date: Mon, 12 Feb 2024 17:03:52 +0000 (+0100) Subject: DOC/MINOR: userlists: mention solutions to high cpu with hashes X-Git-Tag: v3.0-dev4~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=07fd4e8b5e645d9baafed948ccbdbd7b59373c33;p=thirdparty%2Fhaproxy.git DOC/MINOR: userlists: mention solutions to high cpu with hashes This change adds a paragraph to the documentation regarding "userlists" and the use of hashed password value. It indicates what a user can do to address the high CPU cost of having to calculate the hash at each request, such as reducing the number of rounds or the cost complexity, if the algorithm allows for it. I believe it is necessary to mention how the musl C library impacts performance of hashing functions, as this has already led to a few issues: https://github.com/haproxy/haproxy/issues/1298 https://github.com/haproxy/haproxy/issues/2008 https://github.com/haproxy/haproxy/issues/2251 The performance impact is significant enough to mention it. Acked-by: Lukas Tribus --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 47f5153104..e09468ff07 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -3998,7 +3998,15 @@ user [password|insecure-password ] designed to be expensive to compute to achieve resistance against brute force attacks. They do not simply salt/hash the clear text password once, but thousands of times. This can quickly become a major factor in HAProxy's - overall CPU consumption! + overall CPU consumption, and can even lead to application crashes! + + To address the high CPU usage of hash functions, one approach is to reduce + the number of rounds of the hash function (SHA family algorithms) or decrease + the "cost" of the function, if the algorithm supports it. + + As a side note, musl (e.g. Alpine Linux) implementations are known to be + slower than their glibc counterparts when calculating hashes, so you might + want to consider this aspect too. Example: userlist L1