Générateur de .htpasswd

Générez des fichiers .htpasswd pour l'authentification HTTP basique d'Apache et Nginx en toute sécurité dans votre navigateur. Prend en charge bcrypt, APR1-MD5 et SHA-1. Les mots de passe ne sont jamais envoyés au serveur.

Qu'est-ce qu'un fichier .htpasswd ?

Un fichier .htpasswd est un simple fichier texte qui stocke, ligne par ligne, des paires nom d'utilisateur:mot de passe haché. C'est ce fichier que consultent Apache et Nginx lorsqu'ils appliquent une authentification HTTP basique à un répertoire ou à un point d'accès : le serveur compare le nom d'utilisateur saisi par le visiteur et le hachage du mot de passe fourni avec le contenu de ce fichier, et n'autorise l'accès qu'en cas de correspondance. Traditionnellement, on le génère avec la commande htpasswd installée aux côtés d'Apache, mais de nombreux hébergements mutualisés, environnements de conteneurs ou postes de développement ne donnent pas un accès simple au terminal du serveur.

C'est précisément pour ce cas de figure qu'un outil fonctionnant entièrement dans le navigateur est utile : il reproduit le même format de sortie sans jamais nécessiter de connexion SSH ni d'installation de paquet. Cet outil calcule le hachage du mot de passe saisi avec bcrypt, APR1-MD5 ou SHA-1, puis produit une ligne au format nom d'utilisateur:hachage prête à l'emploi. L'ensemble du calcul s'exécute en JavaScript côté client : le mot de passe en clair ne transite jamais sur le réseau. Une fois généré, placez le fichier en dehors du DocumentRoot du serveur et référencez son chemin via la directive AuthUserFile de la configuration Apache ou Nginx.

Comment générer un fichier .htpasswd

  1. Ajoutez une ligne d'utilisateur Cliquez sur le bouton « Ajouter un utilisateur » autant de fois que nécessaire : une ligne correspond à un utilisateur autorisé à s'authentifier sur le serveur.
  2. Saisissez le nom d'utilisateur et le mot de passe Pour chaque ligne, renseignez le nom d'utilisateur et le mot de passe souhaités. L'icône d'affichage permet de basculer entre texte masqué et texte visible afin de vérifier la saisie.
  3. Choisissez l'algorithme et le coût Sélectionnez bcrypt, APR1-MD5 ou SHA-1 pour chaque ligne selon la compatibilité recherchée ; avec bcrypt, ajustez également la valeur de coût (l'exposant qui détermine le nombre d'itérations).
  4. Cliquez sur Générer Le calcul du hachage s'exécute immédiatement dans votre navigateur et un aperçu du contenu complet du fichier .htpasswd s'affiche juste en dessous du formulaire.
  5. Copiez ou téléchargez le résultat Copiez le contenu dans le presse-papiers ou téléchargez-le sous forme de fichier prêt à être déposé sur votre serveur via FTP, SSH ou votre outil de déploiement habituel.

Astuces pour en tirer le meilleur parti

  • Utilisez bcrypt : l'algorithme le plus sécurisé disponible. Compatible avec Apache 2.4+ et Nginx. Plus le coût est élevé, plus le hachage est lent et résistant aux attaques par force brute (10 est une valeur courante).
  • APR1-MD5 ($apr1$) est destiné à la compatibilité avec Apache 2.2 ou antérieur. Il fonctionne avec pratiquement toutes les versions d'Apache et Nginx.
  • SHA-1 ({SHA}) offre une faible résistance aux collisions et n'est pas recommandé. Ne l'utilisez que dans des environnements anciens qui l'exigent.
  • Placez le fichier .htpasswd en dehors du DocumentRoot pour qu'il ne soit pas accessible directement depuis le web.
  • Utilisez toujours HTTPS. Les identifiants d'authentification basique sont simplement encodés en Base64, pas chiffrés — ils transitent en clair sur HTTP.

Cas d'usage

Protéger un environnement de préproduction

Verrouillez rapidement un site en cours de développement pour empêcher les moteurs de recherche et les visiteurs non autorisés d'y accéder avant sa mise en ligne officielle.

Restreindre l'accès à un panneau d'administration interne

De nombreux outils internes ou tableaux de bord maison ne disposent d'aucun système de connexion propre : une authentification basique ajoute une couche de protection minimale mais efficace.

Combiner avec une restriction par adresse IP

Lorsque la restriction par IP seule n'est pas envisageable, par exemple pour des collaborateurs travaillant depuis des adresses variables, associer les deux mécanismes renforce la défense en profondeur.

Protéger uniquement certains points d'accès d'une API

En combinant ce fichier avec les directives location ou Directory de votre configuration serveur, vous pouvez limiter l'authentification à des chemins précis sans affecter le reste du site.

Ajouter de nouveaux utilisateurs à un service déjà en production

Générez uniquement les lignes correspondant aux nouveaux comptes à ajouter, puis ajoutez-les à la fin du fichier .htpasswd existant sans avoir à régénérer l'ensemble des utilisateurs déjà en place.

Glossaire

Authentification basique (Basic Authentication)
Méthode d'authentification standardisée par le protocole HTTP. Le nom d'utilisateur et le mot de passe sont encodés en Base64 et envoyés à chaque requête dans l'en-tête Authorization, puis vérifiés côté serveur avant d'autoriser l'accès à la ressource demandée.
bcrypt
Algorithme de hachage de mot de passe intégrant un sel aléatoire. Sa valeur de coût réglable permet de ralentir volontairement le calcul, ce qui le maintient résistant aux attaques par force brute même à mesure que le matériel informatique gagne en puissance. C'est l'algorithme actuellement recommandé pour ce fichier.
APR1-MD5
Format de hachage propre à Apache, basé sur MD5, dont la sortie commence toujours par $apr1$. Il est conservé principalement pour assurer la compatibilité avec des versions anciennes d'Apache qui ne prennent pas en charge bcrypt.
SHA-1 (préfixe {SHA})
Format de hachage dont la sortie commence par {SHA}. Il ne fait intervenir aucun sel et présente une résistance aux collisions désormais jugée faible ; son usage n'est donc pas recommandé pour de nouveaux déploiements.
Sel (salt)
Chaîne de caractères aléatoire ajoutée au mot de passe avant le calcul du hachage. Elle garantit que deux mots de passe identiques produisent des hachages différents, ce qui rend inefficaces les attaques par table arc-en-ciel précalculée.
DocumentRoot
Répertoire racine à partir duquel un serveur web expose publiquement ses fichiers. Le fichier .htpasswd doit impérativement être placé en dehors de ce répertoire, faute de quoi il pourrait être lu directement depuis un navigateur.
AuthUserFile
Directive de configuration Apache qui indique le chemin absolu vers le fichier .htpasswd à utiliser pour vérifier les identifiants lors d'une authentification basique.

Questions fréquentes

Ajoutez les directives suivantes à votre .htaccess ou httpd.conf, en pointant AuthUserFile vers le fichier .htpasswd généré :
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Ajoutez les directives à votre nginx.conf ou au bloc server concerné :
location /admin {
    auth_basic "Restricted Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
Nginx prend en charge bcrypt et APR1-MD5.

bcrypt est fortement recommandé pour Apache 2.4+ et Nginx. Utilisez APR1-MD5 uniquement si vous avez besoin de compatibilité avec Apache 2.2 ou antérieur. Évitez SHA-1 sauf contrainte d'un système ancien.

Il suffit d'ajouter la ligne générée (utilisateur:hash) à la fin du fichier existant. Chaque ligne représente un utilisateur. Les lignes vides et celles commençant par # sont ignorées.

Oui. Tout le calcul de hachage s'effectue entièrement dans votre navigateur. Aucune donnée de mot de passe n'est transmise au serveur. Utilisez cet outil sur une page HTTPS sécurisée et manipulez le fichier généré avec précaution.
Tool-kun

Anecdote — Pourquoi Basic Auth survit malgré son âge

L'authentification HTTP basique a été définie en 1999 par la RFC 2617 (mise à jour par la RFC 7617). Le mécanisme est simple : concaténer le nom d'utilisateur et le mot de passe avec :, encoder en Base64 et envoyer dans l'en-tête Authorization.

C'est précisément cette simplicité qui explique sa longévité : idéale pour les environnements de staging, les outils internes ou comme première ligne de défense combinée à des listes blanches d'IP. Deux ou trois lignes de configuration suffisent, sans middleware ni base de données supplémentaires.

Ses limites sont cependant réelles : pas de mécanisme de déconnexion (la session persiste jusqu'à la fermeture du navigateur), pas de gestion de l'expiration des mots de passe ni d'authentification multifacteur native. Pour des services en production avec des exigences de sécurité réelles, envisagez OAuth 2.0 ou OIDC.