Stop Using 'password123': A Developer's Guide to Strong Passwords

Every developer knows the drill: create an account, type a "temporary" password, and promise to change it later. Months go by, and that password - often something painfully predictable - is still protecting your production database, your CI/CD pipeline, or your cloud console. Let's fix that. Here's what actually makes a password strong, and how to generate one you can trust.

Length Is Everything

People obsess over adding symbols and uppercase letters, but length is the single biggest factor in password strength. A 16-character all-lowercase password takes centuries to brute-force with today's hardware. An 8-character password with symbols takes hours. Every additional character multiplies the search space exponentially.

A 12-character password using only lowercase letters has 26¹² ≈ 95 quadrillion combinations. Add just 4 more characters, and you jump to 26¹⁶ ≈ 43 sextillion. That's the difference between crackable and effectively uncrackable.

Randomness > Cleverness

Your brain is terrible at randomness. "CorrectHorseBatteryStaple" is predictable because it uses dictionary words. "P@ssw0rd!" is in every rainbow table ever compiled.

The only reliable way to generate a truly strong password is to let a cryptographically secure random number generator do it. In the browser, that means crypto.getRandomValues() - the Web Crypto API backed by your OS's entropy source. It's the same API that password managers like 1Password and Bitwarden use under the hood.

Checking Your Password's Strength

Not all "strong" passwords are equal. A good password generator should show a strength indicator based on:

• Length (the biggest factor - aim for 16+)
• Character variety (lowercase + uppercase + numbers + symbols = 4 character pools)
• True randomness (no human-chosen patterns)

I use a free password generator that shows real-time strength feedback and lets you customize length and charsets. Everything runs locally via crypto.getRandomValues() - the generated password never touches a server.

Quick Tips for Developers

• API keys/tokens: use 32-64 character alphanumeric strings (no symbols - some systems choke on special chars)
• Database passwords: 20+ characters, all four charsets
• Wi-Fi passwords: 20+ characters - they're shared, so make them strong enough to survive a handoff
• Never reuse: a strong password used on two sites is a weak password

The Bottom Line

Stop typing "Summer2026!" and convincing yourself it's fine. Use a generator, pick 16+ characters, and let entropy do the work. Your production environment will thank you.

What's the worst password you've seen in a codebase? (Config files committed to public repos, I'm looking at you.)