El generador adecuado, lenguaje adecuado. No todos los generadores de contraseñas son iguales, y el lenguaje en el que está escrito tu almacén no es un detalle de ingeniería. Analizamos la entropía, los modos de generación y por qué Rust se impone bajo el capó. Cuando un gestor "genera una contraseña segura", hay dos preguntas clave: ¿es realmente impredecible? (la calidad del azar) y ¿qué ocurre con ella en memoria una vez mostrada? La primera depende de los modos de generación. La segunda, del lenguaje que ejecuta la aplicación. Este artículo cubre ambas. ~100 bits contraseña aleatoria de 16 caracteres (muy fuerte) ~77 bits passphrase Diceware de 6 palabras (EFF) 12,9 bits de entropía añadidos por palabra Diceware (lista de 7 776 palabras) Entropía: la única medida que importa La fortaleza de una contraseña no se mide por su "complejidad" percibida, sino por su entropía : el número de bits de incertidumbre para un atacante. Cuantas más combinaciones posibles existan, más se dispara el coste de un ataque por fuerza bruta. Una contraseña de 16 caracteres tomados de todo el alfabeto ASCII alcanza alrededor de 100 bits, dentro del rango "muy fuerte". Un punto crucial que a menudo se olvida: la entropía solo vale si la fuente de aleatoriedad es un CSPRNG (generador pseudoaleatorio criptográficamente seguro). Un Math.random() clásico es predecible y descalifica todo lo demás. Las buenas implementaciones leen la entropía del sistema operativo: /dev/urandom o getrandom(2) en Unix, CNG en Windows. Cuatro familias de generadores Un buen gestor no ofrece "un" generador, sino varios modos adaptados al uso. La regla es simple: la memorabilidad se paga con longitud . Estas son las cuatro familias, de la más densa a la más humana. El reflejo correcto: adaptar la entropía al uso Para una cuenta web protegida por una página de inicio de sesión con límite de tasa, el atacante queda restringido a unos pocos cientos de intentos por segundo: incluso 50 bits resisten durante tiempos geológicos. La sobreentropía solo tiene sentido para secretos fuera de línea (clave de cifrado, seed de una cartera cripto), donde el ataque puede paralelizarse masivamente. Para estos secretos de altísimo valor, tirar dados físicos reales (Diceware en sentido estricto) sigue siendo la opción definitiva: elimina cualquier dependencia de la calidad del CSPRNG o de un navegador comprometido. Por qué Rust cambia las reglas Generar una buena contraseña es solo la mitad del trabajo. La otra mitad: no dejarla tirada . Una vez mostrada o descifrada, tu contraseña vive en memoria RAM, y ahí el lenguaje de la aplicación se vuelve determinante. Microsoft informó de que el 70 % de las vulnerabilidades de seguridad que encuentra son bugs de memoria (buffer overflow, use-after-free, etc.). Google observó la misma proporción en Chrome y Android. Estas son precisamente las clases de fallos que Rust elimina en compilación , mediante su modelo de propiedad ( ownership ) y préstamo ( borrowing ), sin recolector de basura. Las cifras de Google son elocuentes: las vulnerabilidades de memoria de Android cayeron de 223 en 2019 a menos de 50 en 2024 , quedando por primera vez por debajo del 20 % del total. El código nuevo en Rust muestra una densidad de fallos de memoria hasta 1000× inferior a la del código C/C++ histórico, además de 4× menos rollbacks y un 25 % menos de tiempo de revisión. 1. Seguridad de memoria sin recolector de basura. Lenguajes como Java o Python son seguros en memoria, pero su garbage collector libera memoria de forma no determinista: un secreto puede sobrevivir allí indefinidamente, expuesto a un volcado de memoria o a un ataque cold-boot. Rust libera memoria de forma determinista, en cuanto el dato deja de usarse. 2. Borrado explícito con zeroize . Rust no garantiza que la memoria liberada se sobrescriba. La crate zeroize cubre ese hueco: al envolver un secreto en Zeroizing , se garantiza que se sobrescribe con ceros, mediante una escritura volátil que el compilador no puede optimizar, en el momento exacto en que sale de alcance. 3. Un sistema de tipos que fuerza el buen uso de la criptografía. El sistema de tipos estricto de Rust permite delimitar cómo puede usarse un dato sensible, y cuántas veces. Por ejemplo, se puede modelar una clave que solo pueda emplearse una vez, con el compilador rechazando cualquier reutilización. Honestidad técnica: Rust no es una varita mágica El código unsafe y las dependencias de terceros siguen siendo superficies de ataque: Google, de hecho, corrigió una vulnerabilidad (CVE-2025-48530) en un bloque unsafe de un parser Rust antes de cualquier puesta en producción. La seguridad de memoria es una capa , no un fin en sí misma: se combina con defensa en profundidad (KDF robusta como Argon2id, arquitectura zero-knowledge, bloqueo automático, MFA). Qué exigir a un gestor Al elegir, o evaluar, un gestor de contraseñas, hay cuatro preguntas concretas: 1. ¿El generador se basa en un CSPRNG del sistema y muestra la entropía en bits? 2. ¿Ofrece un modo passphrase Diceware/EFF para la contraseña maestra? 3. ¿La generación es local (client-side) , sin tránsito por un servidor? 4. ¿El núcleo sensible está escrito en un lenguaje seguro en memoria con borrado explícito de secretos? Generación segura. Un almacén diseñado para durar. Contraseñas de alta entropía, passphrases memorizables y un núcleo preparado para la seguridad de memoria. Contenido informativo con fines educativos. Las estadísticas citadas (Google/Android, Microsoft, Diceware/EFF) proceden de las fuentes listadas arriba. Los ejemplos de código Rust son ilustrativos y simplificados.