Verification des mots de passe
[auth]
hash_workers = 2 # fils qui calculent les hashs
hash_queue = 1024 # tentatives qui attendent un fil
hash_per_address = 4 # places qu'une adresse peut tenir a la fois
Les options
Les trois cles sont lues au demarrage ; un rechargement ne change pas la
taille du pool. Toutes les cles : Reference [auth].
Comment ca marche
Un hash argon2id, bcrypt ou sha512-crypt est du calcul pur : de 16 ms
(owasp-min) a plus d’une seconde (argon2 lourd). Les verifications tournent
sur des fils dedies (craft-file-gate-hash-0, -1… dans ps -L), hors du
runtime qui sert les transferts, l’API et les sondes.
| Situation | Ce qui se passe |
|---|---|
| un fil libre | la tentative est verifiee aussitot |
| fils occupes, place en file | la tentative attend son tour |
| fils occupes, file pleine | refus immediat, sans recherche du compte, sans compter pour le ban |
l’adresse tient deja hash_per_address places | meme refus, quelle que soit la charge |
| client parti avant son tour | la tentative n’est pas hachee ; sa place est rendue |
| adresse bannie pendant l’attente | la tentative n’est pas hachee ; reponse d’une adresse bannie |
| arret du serveur | aucune nouvelle tentative admise ; celles sur un fil finissent |
Une tentative prend sa place avant la recherche du compte : un nom connu et un nom inconnu recoivent la meme reponse. Les limiteurs de debit et les bans (Bans) bornent ce qu’une rafale coute a la file.
Derriere un reverse proxy, declarez-le dans trusted_proxies : chaque client
compte a sa propre adresse. Une adresse de NAT va dans whitelist_ips de la
porte ([sftp.ban], [api.ban], [admin.ban]), qui n’est pas plafonnee. La
connexion a la console (POST /admin/login) passe par le meme pool.
Choisir les tailles
| Question | Reponse |
|---|---|
| pourquoi 2 fils au plus par defaut | chaque fil peut tenir un m argon2 entier ; 2 fils au profil owasp-min tiennent sous 80 Mo |
| combien de connexions par seconde | 2 fils : une trentaine au profil rfc9106-low-mem (68 ms), plus d’une centaine au profil owasp-min (16 ms) |
| pourquoi 1024 places | une place est une connexion qui attend (~70 Kio en SSH, ~42 Kio en Basic), pas une allocation argon2 ; 100 clients qui se reconnectent ensemble attendent au lieu d’etre refuses |
| attente de la derniere place | hash_queue / hash_workers verifications : 6,5 s avec 2 fils au profil owasp-min ; restez sous sftp.login_grace_secs (120 s) |
| budget memoire serre | une file plus courte, a la taille de la rafale attendue (hash_queue = 32) ; le pool tient hash_workers fois le plus grand m du fichier : Memoire |
Ce que vous verrez
Au demarrage, une ligne dit chaque nombre et sa source :
INFO password hashing pool started: passwords are checked on these threads, off the async runtime, ...
workers=2 workers_source="detected (8 CPUs ...), capped at 2 by default: ..."
queue=1024 queue_source="default (1024, ...)"
per_address=4 per_address_source="default (4 per address, ...)"
peak_memory="2 threads × 19 MiB = 38 MiB"
tokio_workers=8 tokio_workers_source="detected (std::thread::available_parallelism)"
tokio_workers : les fils du runtime async, sur la meme detection sans
plafond, ou TOKIO_WORKER_THREADS.
Un rechargement de users.toml qui change le plus grand m le dit :
INFO password hashing peak memory changed with the users file.
Kubernetes
Un pod sans limits.cpu voit les CPU du noeud (32, 64). Le plafond a 2 protege
le pool par defaut, pas le runtime tokio. Pour suivre ce que le pod demande,
passez requests.cpu par l’API Downward (arrondi a l’entier superieur) :
env:
- name: CRAFT_FILE_GATE_HASH_WORKERS
valueFrom:
resourceFieldRef:
containerName: craft-file-gate
resource: requests.cpu
divisor: "1"
# de meme pour TOKIO_WORKER_THREADS
Une valeur explicite n’a pas de plafond : requests.cpu: 8 donne 8 fils et
8 x m de memoire. Le chart Helm le fait par passwordHashing.workers (vide :
requests.cpu) et passwordHashing.queue.