Générateur .htpasswd — bcrypt 12 avec avis nginx

Que fait le générateur htpasswd ?

Le générateur émet des lignes Apache .htpasswd — pure-client, sans que votre mot de passe quitte le navigateur. Vous choisissez le serveur web (Apache ou nginx), saisissez utilisateur et mot de passe, et le générateur met l’algorithme de hash adéquat par défaut : bcrypt pour Apache, APR1-MD5 pour nginx. Si vous tentez une combinaison incompatible (bcrypt sur nginx), l’avertissement apparaît immédiatement — pas seulement au déploiement production quand crypt_r() failed (22) apparaît dans l’error-log.

Quatre algorithmes de hash sont intégrés, sélectionnés selon l’état de sécurité 2026 :

• bcrypt — défaut OWASP, cost factor 4 / 10 / 12 / 14 au choix. Le benchmark single-shot mesure la latence de hashing réelle sur votre appareil avant le hashing.
• APR1-MD5 — legacy Apache + compatibilité nginx. 1000 itérations MD5 avec salt 8 octets.
• SHA-1 — préfixe {SHA}, sans salt, sans stretching. Uniquement comme fallback nginx si APR1 ne marche pas ; sinon déconseillé.
• crypt (DES) — le standard Apache d’origine. Coupe les mots de passe après 8 caractères, est en 2026 trivialement attaquable par dictionnaire. Uniquement pour setups historiques.

Mode single et mode batch sont des onglets séparés. En batch vous insérez des lignes user:password et obtenez un bloc .htpasswd complet — avec option d’override de cost par entrée. Le compteur de force affiche entropie et avertissements heuristiques (correspondance dictionnaire, substitutions courantes, marches clavier) en direct pendant la frappe.

Quel cost factor bcrypt recommandé en 2026 ?

bcrypt est le seul des quatre algorithmes .htpasswd encore recommandé sans réserve en 2026. L’algorithme date de 1999, basé sur la cipher de bloc Blowfish, et utilise un cost factor adaptatif — à chaque palier le temps de hashing double. Cela rend bcrypt pérenne : si le matériel GPU devient deux fois plus rapide en cinq ans, vous augmentez le cost de un et le niveau de sécurité reste le même.

Le OWASP Password Storage Cheat Sheet recommande pour 2026 cost 12 comme minimum. Le défaut CLI Apache htpasswd est toujours cost 10 — c’était approprié en 2014, trop faible aujourd’hui. Cost 14 est plus conservateur (~1,5 s par hash) mais sensiblement lent pour workflows login.

Le générateur mesure le temps de hashing réel sur votre appareil avant que vous hashiez le mot de passe définitif. Vous voyez : « Cost 12 = 287 ms sur ce navigateur ». Vous pouvez ainsi choisir le cost factor selon la latence plutôt qu’au feeling. Sur navigateurs mobiles lents, cost 11 suffit ; sur desktops modernes, cost 13 reste souvent rapide. Préréglages : 4 (démos), 10 (CLI Apache), 12 (OWASP), 14 (conservateur).

Quel algorithme convient à Apache ou nginx ?

Apache mod_auth_basic plus mod_authn_file acceptent les quatre algorithmes sans souci — le choix recommandé est bcrypt. Le générateur le met automatiquement quand vous sélectionnez « Apache » en haut. Le .htaccess à côté :

AuthType Basic
AuthName "Protected"
AuthUserFile /chemin/vers/.htpasswd
Require valid-user

Vous pouvez construire le bloc adéquat en parallèle avec le générateur .htaccess — on y trouve une règle HTTP Basic Auth avec champs realm et chemin.

nginx est différent. auth_basic_user_file appelle la fonction système crypt() et accepte uniquement les hashes que crypt() comprend : APR1-MD5 ($apr1$), SHA-1 ({SHA}), DES-crypt et plain-text (que vous ne devriez évidemment jamais utiliser). bcrypt est refusé — le générateur bascule automatiquement au toggle serveur web et désactive bcrypt. Qui veut quand même la vérification bcrypt sur nginx utilise OpenResty avec module Lua ou un plugin d’auth dédié — mais hors directive Basic-Auth standard.

Pourquoi APR1-MD5 est-il obsolète et comment migrer ?

APR1-MD5 a un rôle double étrange : obsolète sur Apache, standard sur nginx. L’algorithme utilise 1000 itérations MD5 avec salt 8 octets — encore suffisant en 2010, en 2026 cassable en moins d’une seconde avec brute-force GPU. Qui installe Apache neuf ne devrait jamais prendre APR1 ; qui migre un .htpasswd APR1 existant remplace les lignes une à une par des versions bcrypt.

Étapes de migration :

1. Générer nouveaux hashes bcrypt par utilisateur (mode batch du générateur).
2. Supprimer les anciennes lignes APR1 du .htpasswd, insérer les nouvelles lignes bcrypt.
3. Recharger .htaccess (un reload Apache suffit, pas de restart).
4. Tester le login une fois par utilisateur — Apache vérifie les deux formats en parallèle, le switch est transparent.

Pour les setups nginx la migration est plus compliquée, parce que bcrypt n’est pas accepté. Trois voies : (a) garder APR1 et faire tourner les mots de passe régulièrement, (b) passer à OpenResty + module Lua-Auth, (c) remplacer Basic-Auth entièrement par un système d’auth moderne (OAuth2-Proxy, Authelia, Cloudflare Access). La variante (c) est en 2026 la bonne réponse à long terme — Basic-Auth n’a jamais été pensée comme auth de production.

Comment le mot de passe ne quitte-t-il jamais le navigateur ?

Personne d’autre que vous ne voit ce mot de passe. Le générateur n’a pas d’endpoint serveur pour hashing, pas de ping télémétrie, pas de cookie, pas de compte. La seule utilisation de la Web Crypto API est crypto.getRandomValues pour les octets de salt — cela se passe dans le navigateur, sans appel réseau. L’algorithme bcrypt est intégré comme implémentation pure-JS ; APR1, SHA-1 et crypt également.

Comment le vérifier vous-même :

1. Ouvrir l’outil, DevTools navigateur (F12).
2. Onglet « Réseau » / « Network », filtre sur « Tout ».
3. Saisir le mot de passe, générer le hash.
4. Dans l’onglet réseau aucune requête n’apparaît pendant le hashing — pas de POST, pas de WebSocket, rien.

L’élément form ne porte pas d’attribut action, les inputs ont autocomplete=\"new-password\" pour que votre navigateur ne stocke pas le clair dans son historique form. Quand vous fermez l’onglet, le mot de passe disparaît — le générateur ne persiste rien dans localStorage ou sessionStorage. Pour un audit : le code source est consultable sur GitHub et le lint bloque tout appel fetch dans ce chemin d’outil.

Comment utiliser le mode batch pour setups d’équipe ?

Le mode batch résout le scénario setup d’équipe DevOps : dix développeurs ont besoin d’accès à un environnement staging, chacun avec son propre mot de passe. Vous insérez dix lignes user:password dans le champ batch, choisissez algorithme plus cost factor, et obtenez un fichier .htpasswd complet — un hash par ligne, prêt à uploader sur le serveur.

Le compteur de force tourne par entrée, vous voyez immédiatement qui a pris un mot de passe faible. Optionnel : override de cost par entrée — comptes admin obtiennent cost 14, comptes service cost 12. Le bouton de téléchargement livre le fichier directement au bon format. Combiné avec le générateur .htaccess vous construisez la configuration HTTP-Basic-Auth complète en deux changements d’onglet — .htaccess plus .htpasswd, les deux générés pure-client.

Qu’est-ce qui n’est volontairement pas construit ?

• Pas de suggestions de mot de passe — la génération de mot de passe appartient au générateur de mot de passe dédié, pas dans un émetteur de hash. Mélanger les deux fonctions coûterait de la confiance (FAQ « le générateur voit-il mon mot de passe ? »).
• Pas de cassage de hash — le générateur émet, il ne casse pas. Qui veut rétro-calculer un hash perdu utilise John the Ripper ou hashcat en local — aucun outil navigateur ne peut le faire en temps raisonnable.
• Pas d’intégration SSO/OAuth — HTTP-Basic-Auth est son propre schéma d’auth. Pour l’auth moderne on utilise un provider OIDC, pas .htpasswd. Le générateur sert exactement le cas d’usage classique Basic-Auth.
• Pas de variante Argon2 — Apache htpasswd ne supporte pas Argon2. Qui veut Argon2 configure un module d’auth dédié ou passe à l’auth couche application.

Où trouver plus de détails ?

• Manuel Apache htpasswd 2.4 — documentation CLI officielle
• OWASP Password Storage Cheat Sheet — recommandations algorithmes de hash 2026
• nginx Issue #1154 — le refus bcrypt officiel avec justification
• Manuel OpenSSL 3.0 — primitives cryptographiques sous bcrypt/APR1
• bcrypt sur Wikipédia — histoire, algorithme, mathématiques du cost factor
• MD5 sur Wikipédia — pourquoi MD5 (et donc APR1) est considéré comme non sûr en 2026