Local Password Generators: Strong Custom Keys Server-Free

1.6 quadrillion guesses per second — and why that number should terrify you

In 2024, a cluster of eight RTX 4090 GPUs achieved a hashing rate of 1.6 quadrillion guesses per second against NTLM hashes. That is not a typo. A single 8-character password using uppercase, lowercase, numbers, and symbols — the kind most enterprise portals still "strongly recommend" — falls in under 12 hours. I learned this the hard way in 2019 when a service account I had inherited, one with a "complex" 10-character password, was cracked during a routine red team exercise. The credential had been reused across three internal APIs. The fallout took eleven days to contain.

That experience reshaped how I approach credential generation for infrastructure. I stopped trusting browser autofill, cloud-based generators, and the corporate password manager's built-in generator for service accounts. Instead, I built a workflow around local password generation with custom length and zero data retention. This article is that workflow, distilled.

The 95^N calculation: why length is the only variable that matters

Most password strength meters are performative theater. They reward you for swapping "password" with "P@ssw0rd!" and call it a day. The actual math is simpler and more brutal.

There are 95 printable ASCII characters. A password of length N drawn randomly from that set has 95^N possible combinations. Here is what that looks like in practice:

• 8 characters: 95⁸ = 6.6 × 10¹⁵ combinations → crackable in hours on modern GPU arrays
• 12 characters: 95¹² = 5.4 × 10²³ combinations → months to years, depending on hardware
• 16 characters: 95¹⁶ = 4.4 × 10³¹ combinations → heat death of the universe territory for brute force
• 24 characters: 95²⁴ = 2.9 × 10⁴⁷ combinations → physically impossible to brute force with known physics

Notice that I did not mention special characters, leetspeak substitutions, or any of the NIST SP 800-63B guidance that was walked back in 2017. Complexity rules add marginal entropy. Length multiplies it exponentially. When I generate credentials for database service accounts, API tokens, or Kubernetes secrets, I default to 24 characters of pure random ASCII. The custom length parameter is not a luxury feature — it is the single most important input in any password generator.

The entropy math, made tangible

Each randomly selected ASCII character contributes approximately 6.57 bits of entropy (log₂(95) ≈ 6.57). A 24-character password therefore carries roughly 157 bits of entropy. For context, AES-256 encryption — the standard protecting classified U.S. government data — uses 256-bit keys. Your service account password does not need to match that, but 157 bits places it well beyond any feasible brute-force attack, including quantum-assisted Grover's algorithm searches, which halve effective entropy to 78.5 bits. Still uncrackable in any meaningful timeframe.

0 bytes stored: the architecture that earned my trust

I am going to be blunt about why I will not touch cloud-hosted password generators for sensitive credentials: I have read too many privacy policies. Several popular "free password generator" tools operate on infrastructure that logs request parameters. One well-known generator was caught sending generated strings to an analytics endpoint in 2022. The company called it a bug. I call it a reason to never return.

When I say no data stored, I mean it architecturally, not as a promise. A local password generator that runs entirely client-side — in your browser with JavaScript executed on your machine, or as a CLI tool on your local terminal — has no backend to log to. No database. No API call. No telemetry. The entropy source is crypto.getRandomValues() in the browser or /dev/urandom on Linux, both of which pull from your operating system's CSPRNG. The password is generated, displayed, copied to your clipboard, and then the page state is garbage-collected. Zero persistence. Zero transmission.

How to verify a generator actually stores nothing

Do not take any site's word for it. Open your browser's DevTools, navigate to the Network tab, and generate a password. If you see zero outbound requests during and after generation, you are in the clear. I do this every time I evaluate a new tool. It takes eight seconds and has saved me from at least three tools that quietly phoned home.

For command-line workflows, the equivalent verification is running tcpdump or checking strace for socket syscalls. A genuinely offline generator will produce zero network activity.

The 3-second workflow: generating, deploying, and rotating without friction

Security habits that require more than a few seconds of friction do not survive contact with a Monday morning. I have watched engineers abandon password managers and revert to admin123 because the "secure" workflow required seven clicks and a browser extension update. So I optimized mine down to three seconds.

Here is the exact sequence I use for rotating a database service account password every 90 days:

1. Open the local generator (browser bookmark or alias genpass in terminal). Set length to 24. Ensure character set includes all 95 printable ASCII characters. → 1 second
2. Generate and copy to clipboard. → 1 second
3. Paste into the secret management tool (Vault, AWS Secrets Manager, Doppler — whatever the infrastructure uses). → 1 second

Three seconds. No cloud round-trip. No "was this password leaked?" check that sends your credential to a third-party API. The password exists in three places: the CSPRNG output buffer (ephemeral), your clipboard (cleared in 30 seconds via clipboard manager settings), and the encrypted secrets store. That is the entire surface area.

Character set tuning for constrained systems

Some legacy systems reject certain ASCII characters. Oracle databases, for instance, can choke on the @ symbol in connection strings. Active Directory has historical restrictions on certain special characters in service account passwords. This is where custom character set selection becomes critical. A good local generator lets you toggle specific character classes — uppercase, lowercase, digits, symbols — and even exclude ambiguous characters like l, 1, O, and 0 for passwords that humans might need to transcribe.

When I exclude symbols and generate a 24-character alphanumeric password (62-character set), the entropy drops to roughly 143 bits. Still catastrophic for any attacker. The flexibility to tune the character set without sacrificing security is what makes a local generator with granular controls superior to the "one-size-fits-all" approach of most browser-integrated tools.

90-day rotations: the operational rhythm that keeps entropy meaningful

I rotate service account credentials every 90 days. Not because NIST recommends it for human passwords — they explicitly do not — but because service accounts are non-human identities that accumulate access over time. A service account password that has been in a CI/CD pipeline config file for two years is a liability. The password itself may be 157 bits of uncrackable entropy, but the YAML file it lives in is sitting in a Git repository that three dozen engineers can read.

Rotation limits the blast radius of credential exposure. If a password is leaked through a miscommitted config file, a rotated credential has a maximum 90-day window of usefulness. Combined with 24-character generation and local-only creation, this creates a defense-in-depth posture that has held up across four infrastructure audits I have been through.

The math is simple. If you generate a fresh 24-character password locally every 90 days, with zero data stored and zero network transmission, the only way an attacker obtains that credential is by compromising your secrets management platform directly. At that point, password strength is no longer your weakest link — and that is exactly where you want the failure boundary to sit.

One habit, repeated 40 times a year

I generate approximately 40 new service account credentials per year across the infrastructure I manage. That is 40 opportunities for something to go wrong — a password sent over Slack, a generator that logs to a server, a clipboard that never clears. By compressing the entire workflow into a local, custom-length, zero-retention generator and a three-second deployment sequence, I have reduced those 40 opportunities to 40 non-events.

The strongest password is not the one with the most special characters. It is the one generated locally, at sufficient length, with no trace left behind. Build the habit once. Run it for a year. You will never go back to a cloud generator for anything that matters.