Generador de contraseñas htpasswd

Funciones

• Seis formas: bcrypt ($2y$), APR1-MD5 ($apr1$), SHA-1 ({SHA}), SHA-256, SHA-512 y texto sin formato
• Con nginx elige APR1 — nginx no admite bcrypt $2y$ y falla con crypt_r() failed
• Factor de coste de bcrypt ajustable, de 4 a 15
• La salida de APR1 coincide exactamente con openssl passwd -apr1
• La línea .htpasswd, el hash suelto, un comando htpasswd y un comando Docker de una línea
• SHA-256 / SHA-512 se marcan como no estándar: ni Apache ni nginx los aceptan, así que reciben un comando de openssl
• Fuerza de la contraseña (entropía y nivel) al lado, para que una contraseña débil salte a la vista
• La contraseña en los comandos va entre comillas simples, así que $ y comillas sobreviven al shell
• El texto sin formato incluye una advertencia explícita
• Ni el usuario ni la contraseña se suben: todo es local

Cómo se usa

1. Escribe la contraseña en el campo de entrada
2. Indica el usuario (predeterminado admin) y elige un algoritmo
3. La línea .htpasswd y los comandos aparecen a la vez; la última fila es la fuerza de la contraseña
4. Copia la línea que necesites

Preguntas frecuentes

¿Qué algoritmo debería elegir?

bcrypt, para cualquier cosa nueva. Tiene un factor de coste ajustable y tarda decenas de milisegundos en verificar, lo que encarece muchísimo la fuerza bruta. APR1-MD5 es un diseño de los años noventa (mil rondas de MD5: suficiente para ser doloroso entonces e insignificante hoy) y se conserva solo por compatibilidad con configuraciones existentes. SHA-1 no debería usarse para nada relacionado con la seguridad. El texto sin formato es solo para pruebas locales.

¿Qué factor de coste para bcrypt?

El predeterminado es 10 (unos 60 ms). El número equilibra dos cosas: tu servidor dedica ese tiempo a cada verificación, y un atacante también. Cada paso lo duplica: 12 es una elección habitual, mientras que 15 añade casi dos segundos a cada petición. Salvo que te enfrentes a atacantes con hardware dedicado, de 10 a 12 sobra.

¿Cómo uso el resultado?

Añade la «línea .htpasswd» al archivo .htpasswd de tu servidor (una línea por usuario) y luego apunta Apache a él con AuthUserFile, activando AuthType Basic y require valid-user; en Nginx usa auth_basic y auth_basic_user_file. Mantén el archivo fuera de la raíz web, o se podrá descargar sin más.

¿Se sube o se registra la contraseña?

No. El hash se calcula en el navegador y la página no envía ninguna petición: una contraseña es lo último que debería pasar por el servidor de otro, y aquí no hay ningún servidor por el que pasar.

¿nginx admite bcrypt?

No. El `auth_basic_user_file` de nginx acepta oficialmente tres formas: crypt(), apr1 y {scheme}. El `$2y$` que produce `htpasswd -B` es la variante bcrypt de Apache, y apuntar nginx a él suele fallar con `crypt_r() failed (22: Invalid argument)` o directamente con un 500. Usa APR1-MD5 cuando el servidor sea nginx y reserva bcrypt para Apache 2.4+.

¿htpasswd admite SHA-256?

No, y muchas herramientas en línea omiten decirlo. El comando htpasswd tiene exactamente cinco opciones: `-B` (bcrypt), `-m` (apr1), `-s` (SHA-1), `-d` (crypt) y `-p` (texto sin formato). No hay SHA-256, y ni Apache ni nginx reconocen una entrada `{SHA256}`. Aquí se ofrecen SHA-256 y SHA-512 porque algunos sistemas (LDAP al estilo RFC 2307, autenticación propia) sí aceptan esa forma, pero no apuntes Apache ni nginx a ella: la comprobación fallará sin más. La fila del resultado se etiqueta como no estándar para advertirlo.