The right generator, language . Not all password generators are equal, and the language your vault is written in is not just an engineering detail. A closer look at entropy, generation modes, and why Rust is becoming essential under the hood. When a manager "generates a strong password", two questions matter: is it truly unpredictable (the quality of the randomness), and what happens to it in memory once it is displayed? The first question belongs to generation modes. The second belongs to the language running the application. This article covers both. ~100 bits random 16-character password (very strong) ~77 bits 6-word Diceware passphrase (EFF) 12.9 bits of entropy added per Diceware word (7,776-word list) Entropy: the only measure that matters Password strength is not measured by its perceived "complexity", but by its entropy : the number of bits of uncertainty for an attacker. The more possible combinations there are, the more the cost of a brute-force attack explodes. A 16-character password drawn from the full ASCII alphabet reaches roughly 100 bits, which is firmly in "very strong" territory. A crucial point is often forgotten: entropy only matters if the randomness source is a CSPRNG (cryptographically secure pseudo-random number generator). A classic Math.random() is predictable and invalidates everything else. Good implementations read entropy from the operating system: /dev/urandom or getrandom(2) on Unix, CNG on Windows. Four families of generators A good manager does not offer just "one" generator, but several modes suited to different uses. The rule is simple: memorability costs length . Here are the four families, from the densest to the most human-friendly. The right reflex: match entropy to the use case For a web account protected by a rate-limited login page, the attacker is throttled to a few hundred attempts per second: even 50 bits last geological time spans. Extra entropy only really matters for offline secrets (encryption key, crypto wallet seed), where attacks can be massively parallelized. For these very high-value secrets, rolling real physical dice (Diceware in the strict sense) remains the ultimate option: it removes any dependency on the quality of the CSPRNG or on a compromised browser. Why Rust changes the game Generating a good password is only half the job. The other half is not leaving it lying around . Once displayed or decrypted, your password lives in RAM, and that is where the application language becomes decisive. Microsoft reported that 70% of the security vulnerabilities it encounters are memory bugs (buffer overflow, use-after-free, and so on). Google observed the same proportion in Chrome and Android. These are precisely the classes of flaws that Rust eliminates at compile time through its ownership ( ownership ) and borrowing ( borrowing ) model, without a garbage collector. Google's numbers are telling: Android memory vulnerabilities fell from 223 in 2019 to fewer than 50 in 2024 , dropping below 20% of the total for the first time. New Rust code shows a memory flaw density up to 1000x lower than legacy C/C++ code, with 4x fewer rollbacks and 25% less review time as a bonus. 1. Memory safety without a garbage collector. Languages like Java or Python are memory-safe, but their garbage collector frees memory non-deterministically: a secret can survive there indefinitely, exposed to a memory dump or a cold-boot attack. Rust frees memory deterministically as soon as the data is no longer used. 2. Explicit wiping with zeroize . Rust does not guarantee that freed memory is overwritten. The zeroize crate fills that gap: by wrapping a secret in Zeroizing , it guarantees the secret is overwritten with zeros, through a volatile write the compiler cannot optimize away, at the exact moment it goes out of scope. 3. A type system that enforces correct crypto usage. Rust's strict type system can constrain how sensitive data may be used, and how many times. For example, you can model a key that can only be used once, with the compiler rejecting any reuse. Technical honesty: Rust is not a magic wand The unsafe code and third-party dependencies remain attack surfaces. Google even fixed a flaw (CVE-2025-48530) in an unsafe block of a Rust parser before any production rollout. Memory safety is a layer , not an end in itself: it combines with defense in depth (a robust KDF like Argon2id, zero-knowledge architecture, auto-locking, MFA). What to demand from a manager When choosing, or evaluating, a password manager, ask four concrete questions: 1. Does the generator rely on a system CSPRNG , and does it display entropy in bits? 2. Does it offer a Diceware/EFF passphrase mode for the master password? 3. Is generation local (client-side) , with no transit through a server? 4. Is the sensitive core written in a memory-safe language with explicit secret wiping? Secure generation. A vault built to last. High-entropy passwords, memorable passphrases, and a core designed for memory safety. Informational content for educational purposes. The cited statistics (Google/Android, Microsoft, Diceware/EFF) come from the sources listed above. The Rust code examples are illustrative and simplified.