Générateur htpasswd
Générez des lignes .htpasswd pour Apache et nginx dans votre navigateur, avec apr1 et SHA-512 crypt, salts aléatoires et snippets prêts à copier.
Ce générateur htpasswd construit les lignes de mots de passe qu'Apache et nginx lisent pour l'authentification HTTP basic, et il fait tout le travail dans votre navigateur, donc le mot de passe ne voyage jamais vers un serveur. Tapez un nom d'utilisateur et un mot de passe, choisissez Apache MD5 (apr1), SHA-512 crypt ou le format SHA-1 legacy, et vous obtenez une ligne prête à coller, hashée localement avec un salt aléatoire frais issu de crypto.getRandomValues. Empilez autant d'utilisateurs que nécessaire, puis copiez le fichier complet. Comme la crypto faite maison échoue en silence, la page vérifie son propre code apr1 et SHA-512 crypt contre des vecteurs de test connus au chargement. Elle fournit aussi des snippets nginx et .htaccess prêts à copier, plus la commande bcrypt honnête à lancer sur le serveur.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur .htpasswd côté navigateur pour Apache et nginx
Basic auth, c'est le ruban adhésif de la sécurité web, et je le dis comme un compliment. Le truc agaçant, c'est que presque tous les générateurs .htpasswd du marché commencent par envoyer votre mot de passe au serveur de quelqu'un d'autre, ce qui ruine tout l'intérêt. Pas celui-ci. Vous tapez un nom d'utilisateur et un mot de passe, vous choisissez un format, et vous obtenez une ligne .htpasswd prête à coller, hashée directement dans votre navigateur avec un salt aléatoire frais issu de crypto.getRandomValues. Empilez autant d'utilisateurs que nécessaire, puis copiez le fichier complet. Et comme la crypto faite maison échoue en silence, cette page vérifie ses propres implémentations APR1-MD5 et SHA-512 crypt contre des vecteurs de test connus à chaque chargement. Si un contrôle échoue, vous voyez un bandeau rouge au lieu d'un hash faux.
Vos mots de passe ne quittent jamais cette page. Le hashing, c'est du JavaScript local pur, les salts viennent de crypto.getRandomValues, et vous pouvez garder l'onglet réseau ouvert pour constater qu'il ne se passe rien. Le champ mot de passe reste visible exprès : comme ça, vous voyez exactement ce que vous hashez.
Votre fichier .htpasswd
htpasswd -B -c /etc/nginx/.htpasswd alice (retirez -c une fois le fichier créé), ou htpasswd -nbB alice 'YourPassphrase' pour juste afficher la ligne.Snippet nginx
Bloc .htaccess Apache
# .htaccess dans le répertoire à protéger AuthType Basic AuthName "Restricted area" AuthUserFile /etc/apache2/.htpasswd Require valid-user
Ce que fait ce générateur htpasswd
Ce générateur htpasswd construit les lignes de mots de passe qu'Apache et nginx lisent pour l'authentification HTTP basic, et il fait tout le travail dans votre navigateur, donc le mot de passe ne voyage jamais vers un serveur. Un fichier .htpasswd ne peut pas être plus simple : une ligne par utilisateur, le nom d'utilisateur, deux-points, puis le hash du mot de passe. Le préfixe de ce hash indique au serveur quel schéma exécuter quand quelqu'un tente de se connecter, et c'est dans ce préfixe que se joue la vraie décision. Tapez un nom d'utilisateur et un mot de passe, choisissez un format, et vous obtenez une ligne à coller directement dans le fichier. Ajoutez autant d'utilisateurs que nécessaire, puis copiez le tout.
Comment les formats diffèrent, et lequel choisir
- $apr1$ est la variante MD5 maison d'Apache : mille rounds sur un salt de 8 caractères, avec un alphabet base64 custom un peu bizarre. C'est vieux, mais le salt et les itérations le tiennent bien à l'écart du MD5 brut, et la compatibilité est imbattable. Apache, nginx, lighttpd, les vieux NAS poussiéreux, tout le monde l'accepte.
- $6$ est SHA-512 crypt, le schéma crypt(3) de la glibc : 5000 rounds par défaut sur un salt de 16 caractères. Plus solide qu'apr1 sur tous les plans. Le hic, c'est le support. nginx le vérifie via la fonction crypt() du système, qui le gère sur n'importe quel Linux normal, alors qu'Apache n'a appris le schéma qu'assez récemment. Testez un login avant de vous reposer dessus.
- Le format SHA-1 legacy est simplement le base64 d'un digest SHA-1 sans salt. Aucun salt, donc deux utilisateurs avec le même mot de passe obtiennent des lignes identiques. Il est là pour l'interop legacy, rien d'autre.
- bcrypt est volontairement lent, exactement ce qu'il faut face aux rigs de cracking GPU. Cette page ne le simulera pas ; lancez
htpasswd -Bsur le serveur à la place.
Pourquoi basic auth a encore sa place
C'est à la mode de ricaner sur HTTP basic auth, et je comprends. Pas de verrouillage, pas de sessions, une boîte de login qui sent 1997. Et pourtant, quand vous devez garder un site de staging hors de portée de Google et du patron de votre client jusqu'au jour du lancement, basic auth, c'est deux lignes de config et un fichier. Pas de parcours d'inscription, pas de JavaScript, pas de session store à surveiller. Tous les serveurs et tous les navigateurs sortis depuis les années 90 le comprennent. Je m'en sers aussi comme deuxième clôture devant des panneaux d'admin : un bot doit franchir le prompt basic auth avant même de pouvoir marteler le vrai formulaire de connexion, et la plupart n'essaient jamais.
Les limites de sécurité, sans langue de bois
HTTPS ou rien. Avec basic auth, les identifiants voyagent encodés en base64 dans un header à chaque requête, et base64, c'est de l'encodage, pas du chiffrement. N'importe qui écoute le câble en HTTP simple récupère le mot de passe en clair. Il n'y a pas non plus de verrouillage intégré, donc la vitesse du hash et la longueur du mot de passe portent toute la défense. C'est la vraie raison pour laquelle bcrypt bat apr1 : un hash basé sur MD5 tourne à une vitesse absurde sur GPU, des milliards d'essais par seconde, et une passphrase longue réduit cet écart plus que n'importe quel choix de format. Associez l'endpoint à fail2ban ou à du rate limiting nginx s'il compte, gardez le fichier hors du web root avec des permissions que seul l'utilisateur du serveur peut lire, et ne réutilisez pas un mot de passe qui compte pour vous.
Questions fréquentes
Est-ce que je peux taper un vrai mot de passe sur cette page sans risque ?
Rien de ce que vous tapez ici ne quitte votre navigateur. Pas de soumission de formulaire, pas de fetch ; le hashing tourne en JavaScript local et les salts viennent de crypto.getRandomValues. Vous pouvez ouvrir l'onglet réseau et constater qu'il ne se passe rien. Cela dit, pour des identifiants de production, un peu de paranoïa saine ne fait pas de mal : générez-les sur le serveur avec htpasswd et son prompt de mot de passe, cette page ne s'en vexera pas.
Pourquoi pas d'option bcrypt ?
Parce que je ne pouvais pas le faire honnêtement. bcrypt dans le navigateur, ça veut dire embarquer une grosse librairie tierce, et cette page refuse d'émettre le moindre hash qu'elle ne peut pas vérifier contre des vecteurs de test connus au chargement. Alors plutôt qu'une option bidon, vous avez la vraie commande : lancez htpasswd -B -c /etc/nginx/.htpasswd alice sur le serveur et vous aurez une vraie ligne bcrypt en quelques secondes.
Quel format choisir, concrètement ?
bcrypt d'abord, si vous pouvez lancer une commande sur un serveur. Ensuite, apr1 reste le roi de la compatibilité : tous les Apache et nginx du monde l'acceptent. SHA-512 crypt est plus solide sur le papier, mais le support dépend de l'implémentation crypt() de votre serveur, donc testez-le une fois avant de le déployer. Le format SHA-1 legacy est sans salt et présent ici uniquement pour les vieux systèmes.
Où placer le fichier .htpasswd ?
Hors du web root, point final. /etc/nginx/.htpasswd ou /etc/apache2/.htpasswd sont les emplacements habituels. Apache bloque par défaut les requêtes vers les fichiers commençant par .ht, mais c'est une ceinture de sécurité, pas une raison de garer le fichier dans un répertoire public. Et vérifiez les permissions : l'utilisateur du serveur a besoin de lire le fichier, personne d'autre.
nginx accepte-t-il tous ces formats ?
apr1 et le format SHA-1 legacy marchent partout où nginx tourne. Pour SHA-512 crypt, nginx délègue la vérification à la fonction crypt() du système, qui le gère sur n'importe quel Linux normal. Les lignes bcrypt passent aussi quand la libcrypt du système connaît le schéma, ce qui est le cas des distributions modernes basées sur libxcrypt. Dans le doute, créez un utilisateur de test et essayez de vous connecter avant de protéger quoi que ce soit de réel.
Basic auth, c'est vraiment sécurisé ?
Sur HTTPS, c'est une barrière raisonnable. Sur HTTP simple, ce n'est rien : les identifiants voyagent encodés en base64 à chaque requête, et base64, c'est de l'encodage, pas du chiffrement. Il n'y a pas non plus de verrouillage intégré, donc ajoutez du rate limiting ou fail2ban si l'endpoint compte. Je l'utiliserais volontiers pour garder un site de staging privé. Je ne l'utiliserais pas comme seule authentification sur quoi que ce soit qui héberge des données utilisateurs.