Generador .htpasswd — bcrypt 12 con aviso nginx

¿Qué hace el generador htpasswd?

El generador emite líneas Apache .htpasswd — pure-client, sin que su contraseña abandone el navegador. Usted elige el servidor web (Apache o nginx), introduce usuario más contraseña, y el generador pone el algoritmo de hash adecuado por defecto: bcrypt para Apache, APR1-MD5 para nginx. Si intenta una combinación incompatible (bcrypt en nginx), el aviso aparece de inmediato — no solo en el despliegue de producción cuando crypt_r() failed (22) aparece en el registro de errores.

Cuatro algoritmos de hash integrados, seleccionados según el estado de seguridad 2026:

• bcrypt — predeterminado OWASP, cost factor 4 / 10 / 12 / 14 a elegir. El benchmark single-shot mide la latencia de hashing real en su dispositivo antes del hashing.
• APR1-MD5 — legacy Apache + compatibilidad nginx. 1000 iteraciones MD5 con salt de 8 bytes.
• SHA-1 — prefijo {SHA}, sin salt, sin estiramiento de clave. Solo como respaldo para nginx si APR1 no funciona; en otro caso no recomendado.
• crypt (DES) — el estándar original de Apache. Corta contraseñas tras 8 caracteres y en 2026 resulta trivialmente atacable por diccionario. Solo para configuraciones históricas.

El modo único y el modo por lotes son pestañas separadas. En el modo por lotes usted inserta líneas user:password y obtiene un bloque .htpasswd completo — con opción de anular el cost por entrada. El medidor de fuerza muestra entropía y avisos heurísticos (coincidencias con diccionario, sustituciones habituales, paseos por teclado) en directo mientras teclea.

¿Qué cost factor bcrypt se recomienda en 2026?

bcrypt es el único de los cuatro algoritmos .htpasswd que en 2026 sigue recomendándose sin reservas. El algoritmo es de 1999, está basado en el cifrado por bloques Blowfish y usa un cost factor adaptativo — por nivel se duplica el tiempo de hashing. Esto hace bcrypt a prueba de futuro: si el hardware GPU se vuelve el doble de rápido en cinco años, usted sube el cost en uno y el nivel de seguridad se mantiene.

El OWASP Password Storage Cheat Sheet recomienda para 2026 cost 12 como mínimo. El valor predeterminado del CLI Apache htpasswd sigue siendo cost 10 — era apropiado en 2014, hoy es demasiado débil. Cost 14 es más conservador (~1,5 s por hash) pero notablemente lento para flujos de inicio de sesión.

El generador mide el tiempo de hashing real en su dispositivo antes de hashear la contraseña definitiva. Usted ve: «Cost 12 = 287 ms en este navegador». Así puede elegir cost factor por latencia en lugar de por intuición. En navegadores móviles lentos basta cost 11; en escritorios modernos cost 13 sigue siendo a menudo ágil. Preajustes: 4 (demos), 10 (CLI Apache), 12 (OWASP), 14 (conservador).

¿Qué algoritmo encaja con Apache o nginx?

Apache mod_auth_basic más mod_authn_file aceptan los cuatro algoritmos sin problema — la elección recomendada es bcrypt. El generador lo establece automáticamente cuando usted selecciona «Apache» arriba. El .htaccess correspondiente:

AuthType Basic
AuthName "Protected"
AuthUserFile /ruta/a/.htpasswd
Require valid-user

Puede construir el bloque adecuado en paralelo con el generador .htaccess — allí hay una regla HTTP Basic Auth con campos de realm y ruta.

nginx es distinto. auth_basic_user_file llama a la función del sistema crypt() y solo acepta hashes que crypt() entiende: APR1-MD5 ($apr1$), SHA-1 ({SHA}), DES-crypt y texto en claro (que nunca debería usarse, claro). bcrypt se rechaza — el conmutador de servidor web del generador desactiva bcrypt automáticamente para nginx. Quien quiera de todos modos verificación bcrypt en nginx usa OpenResty con módulo Lua o un plugin de autenticación dedicado — pero ambos quedan fuera de la directiva Basic-Auth estándar.

¿Por qué APR1-MD5 es obsoleto y cómo se migra?

APR1-MD5 tiene un rol doble peculiar: en Apache obsoleto, en nginx estándar. El algoritmo usa 1000 iteraciones MD5 con salt de 8 bytes — en 2010 aún suficiente, en 2026 rompible en menos de un segundo con fuerza bruta GPU. Quien monte una instalación Apache nueva no debería recurrir nunca a APR1; quien migre un .htpasswd APR1 existente sustituye las líneas paso a paso por versiones bcrypt.

Pasos de migración:

1. Genere nuevos hashes bcrypt por usuario (modo por lotes del generador).
2. Borre las líneas antiguas APR1 de .htpasswd e inserte las nuevas líneas bcrypt.
3. Recargue .htaccess (basta una recarga de Apache, sin reinicio).
4. Pruebe el inicio de sesión una vez por usuario — Apache verifica ambos formatos en paralelo, el cambio es transparente.

Para configuraciones nginx la migración es más complicada, porque bcrypt no se acepta. Tres caminos: (a) mantener APR1 y rotar contraseñas regularmente, (b) pasar a OpenResty + módulo Lua-Auth, (c) sustituir Basic-Auth entera por un sistema de autenticación moderno (OAuth2-Proxy, Authelia, Cloudflare Access). La variante (c) es en 2026 la respuesta correcta a largo plazo — Basic-Auth nunca se pensó como autenticación de producción.

¿Cómo no abandona nunca la contraseña el navegador?

Esta contraseña no la ve nadie salvo usted. El generador no tiene endpoint de servidor para hashing, sin ping de telemetría, sin cookie, sin cuenta. El único uso de la Web Crypto API es crypto.getRandomValues para los bytes de salt — eso ocurre en el navegador, sin llamada de red. El algoritmo bcrypt está integrado como implementación pure-JS; APR1, SHA-1 y crypt también.

Cómo comprobarlo usted mismo:

1. Abra la herramienta, abra DevTools del navegador (F12).
2. Pestaña «Red» / «Network», filtro en «Todo».
3. Introduzca la contraseña, genere el hash.
4. En la pestaña de red no aparece ni una sola petición durante el hashing — sin POST, sin WebSocket, nada.

El elemento form no lleva atributo action, las entradas tienen autocomplete=\"new-password\" para que su navegador no almacene el texto en claro en su historial de formularios. Cuando cierra la pestaña, la contraseña desaparece — el generador no persiste nada en localStorage ni sessionStorage. Quien necesite auditoría: el código fuente es consultable en GitHub y el lint bloquea cualquier llamada fetch en esta ruta de herramienta.

¿Cómo uso el modo por lotes para configuraciones de equipo?

El modo por lotes resuelve el escenario de configuración de equipo DevOps: diez desarrolladores necesitan acceso a un entorno de staging, cada uno con su propia contraseña. Usted inserta diez líneas user:password en el campo de lotes, elige algoritmo más cost factor, y obtiene un archivo .htpasswd completo — un hash por línea, listo para subir al servidor.

El medidor de fuerza corre por entrada, usted ve de inmediato quién ha elegido una contraseña débil. Opcional: anulación de cost por entrada — las cuentas de administrador reciben cost 14, las cuentas de servicio cost 12. El botón de descarga entrega el archivo directamente en el formato correcto. Combinado con el generador .htaccess usted construye la configuración HTTP-Basic-Auth completa en dos cambios de pestaña — .htaccess más .htpasswd, ambos generados pure-client.

¿Qué se ha dejado fuera deliberadamente?

• Sin sugerencias de contraseña — la generación de contraseñas pertenece al generador de contraseñas dedicado, no a un emisor de hash. Mezclar ambas funciones costaría confianza (FAQ «¿ve el generador mi contraseña?»).
• Sin cracking de hash — el generador emite, no rompe. Quien quiera recuperar un hash perdido usa John the Ripper o hashcat en local — ninguna herramienta de navegador puede hacerlo en tiempo razonable.
• Sin integración SSO/OAuth — HTTP-Basic-Auth es su propio esquema de autenticación. Para autenticación moderna se usa un proveedor OIDC, no .htpasswd. El generador sirve exactamente al caso de uso clásico Basic-Auth.
• Sin variante Argon2 — Apache htpasswd no soporta Argon2. Quien quiera Argon2 configura un módulo de autenticación dedicado o pasa a autenticación de capa de aplicación.

¿Dónde encuentro más detalles?

• Manual Apache htpasswd 2.4 — documentación CLI oficial
• OWASP Password Storage Cheat Sheet — recomendaciones de algoritmo de hash 2026
• nginx Issue #1154 — el rechazo oficial bcrypt con justificación
• Manual OpenSSL 3.0 — primitivas criptográficas bajo bcrypt/APR1
• bcrypt en Wikipedia — historia, algoritmo, matemáticas del cost factor
• MD5 en Wikipedia — por qué MD5 (y con ello APR1) se considera inseguro en 2026