Un generador de contraseñas seguras es la primera línea de defensa contra ataques de fuerza bruta y credential stuffing. Nuestra herramienta usa la Web Crypto API del navegador, la misma primitiva criptográfica que emplean bancos y gestores profesionales, para producir contraseñas verdaderamente aleatorias sin enviar nada a un servidor. Aquí explicamos por qué la longitud pesa más que la complejidad, cómo elegir el juego de caracteres adecuado y qué políticas seguir en 2026 según OWASP y NIST.
Cómo se genera una contraseña realmente aleatoria
Detrás del botón hay una llamada a crypto.getRandomValues(), un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) que obtiene entropía del sistema operativo. Para cada carácter se muestrea un índice del alfabeto configurado y se descartan los sesgos por módulo (rejection sampling), garantizando que cada símbolo tiene exactamente la misma probabilidad. Todo ocurre en cliente: la contraseña nunca viaja por la red, nunca se guarda en logs y no queda en el historial del portapapeles del sistema salvo que tú lo copies.
Longitud vs complejidad: qué prioriza NIST 800-63B
La guía NIST 800-63B eliminó en 2020 la obligación de mezclar mayúsculas, símbolos y números si la contraseña es lo bastante larga. Una contraseña aleatoria de 20 caracteres alfanuméricos ofrece unos 119 bits de entropía; una de 12 con símbolos, unos 78 bits. Con 100 GH/s (tarjeta gráfica moderna) romper 78 bits ya es inviable, pero 119 bits está fuera del alcance incluso de estados. Regla práctica: 16 caracteres para servicios sensibles, 20+ para claves administrativas, 30+ para material criptográfico maestro.
Contraseñas humanas vs contraseñas máquina
Si la contraseña la va a memorizar una persona, usa una passphrase de 4-6 palabras diceware (~50-77 bits). Si la va a guardar un gestor (KeePass, 1Password, Bitwarden), genera cadenas alfanuméricas o con símbolos: son más densas y ocupan menos. Para tokens API, secretos JWT o claves HMAC, usa cadenas largas (48+ caracteres) puramente aleatorias en Base64 o hexadecimal.
Errores frecuentes al generar y almacenar contraseñas
El fallo típico no está en la generación sino en el almacenamiento: copiar la contraseña en un documento de texto, enviarla por correo o pegarla en un Slack. Usa siempre un gestor con cifrado end-to-end. Otro error es reutilizar la misma contraseña en varios servicios: una filtración en un foro puede exponer tu banco. Comprueba tus emails en Have I Been Pwned y activa 2FA en cada servicio que lo permita.
Casos de uso comunes
- Rotar credenciales de bases de datos, servidores y paneles administrativos.
- Generar secretos para variables de entorno (JWT_SECRET, SESSION_SECRET).
- Crear contraseñas para nuevos usuarios en scripts de aprovisionamiento.
- Emitir credenciales temporales para acceso de terceros.
Buenas prácticas
- Mínimo 16 caracteres para usuarios finales, 24+ para cuentas de servicio.
- Almacena en un gestor con cifrado zero-knowledge, nunca en texto plano.
- Combina siempre con 2FA (TOTP o passkey WebAuthn).
- Rota contraseñas críticas cada 90-180 días o tras cualquier incidente.
- No fuerces a los usuarios a caracteres especiales si permites longitud >12; reduce la usabilidad sin ganar seguridad.