From: Daniel Schneller Date: Mon, 6 Nov 2017 15:51:04 +0000 (+0100) Subject: DOC: Add note about encrypted password CPU usage X-Git-Tag: v1.8-rc3~39 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d06f31c443bbaa231ef75221540dec605d20018b;p=thirdparty%2Fhaproxy.git DOC: Add note about encrypted password CPU usage From first-hand experience I realized that using encrypted passwords in userlists can quickly become overwhelming for busy sites. In my case just about 100 rq/s were enough to drive (user) CPU usage from 2-3% up to >90%. While it is perfectly explicable why this is the case, having it mentioned in the relevant documentation section might spare someone some confusion in the future. --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 5477766afc..7a8fb079d3 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -1690,11 +1690,20 @@ user [password|insecure-password ] [groups ,,(...)] Adds user to the current userlist. Both secure (encrypted) and insecure (unencrypted) passwords can be used. Encrypted passwords are - evaluated using the crypt(3) function so depending of the system's - capabilities, different algorithms are supported. For example modern Glibc - based Linux system supports MD5, SHA-256, SHA-512 and of course classic, - DES-based method of encrypting passwords. - + evaluated using the crypt(3) function, so depending on the system's + capabilities, different algorithms are supported. For example, modern Glibc + based Linux systems support MD5, SHA-256, SHA-512, and, of course, the + classic DES-based method of encrypting passwords. + + Attention: Be aware that using encrypted passwords might cause significantly + increased CPU usage, depending on the number of requests, and the algorithm + used. For any of the hashed variants, the password for each request must + be processed through the chosen algorithm, before it can be compared to the + value specified in the config file. Most current algorithms are deliberately + 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! Example: userlist L1