Two years ago I kept a test server open to the internet on a fixed IP. One morning a text from the cloud provider arrived: successful login from an unusual location. I went through the authentication log and found more than 47,000 Failed password entries from the previous night, spread across a dozen subnets. Nobody was guessing passwords; a script was scanning. The uglier detail was the successful entry: user name root, password a six-digit number I had set casually three years earlier on a temporary box. Nobody had used that machine in ages, I could not even remember the password, and port 22 was still open.
After that I reworked the credentials on every account I had, and learned that password strength is not solved by adding a symbol.
1. Cracking is not guessing, it is counting through orders of magnitude
Time depends on two variables: length and character set size. But the assumptions have to be stated first. The two rates below, about one billion guesses per second on an ordinary CPU and about one hundred billion on a GPU cluster, apply only to an offline attack where the attacker already has the password store and the store holds unsalted fast hashes (MD5, SHA1 and the like). If the other side is facing bcrypt, Scrypt or Argon2, the effective rate on the same hardware drops by three to six orders of magnitude, and every duration in the table below is multiplied by a thousand to a million.
Feed the numbers into that worst case and the results look like this. You can divide them yourself: combinations divided by 10⁹ gives seconds, and dividing again by the number of seconds in a year, about 3.16×10⁷, gives years.
| Password composition | Combinations | Time at one billion per second |
|---|---|---|
| 8 lowercase letters (26 symbols) | about 2.09×10¹¹ | about 3.5 minutes |
| 10 lowercase letters (26 symbols) | about 1.41×10¹⁴ | about 39 hours |
| 12 mixed case plus digits (62 symbols) | about 3.23×10²¹ | about 102,000 years |
| 16 mixed case, digits and symbols (94 symbols) | about 3.72×10³¹ | about 1.18×10¹⁵ years |
The pattern is plain: each extra character multiplies the count by the size of the character set, and 26 to the fourth power is 456976, so one more character makes it 456976×26. The same thing can be written as entropy, roughly length times log2 of the character set: at 16 characters from a 94-symbol set, log2(94) is about 6.55, so 16×6.55 gives about 105 bits; 8 lowercase letters give only 8×4.70, about 38 bits. When I say effectively uncrackable, the 105 bits are what I am relying on, not a symbol I added on a whim. So the order I set for myself is: make it long first, then talk about mixing.
2. Why human-made complex passwords get hit first
The strings 123456, password and qwerty show up again and again in breach corpora. In the NordPass 2024 list of common passwords, compiled from publicly leaked data (including dark web sources, roughly 2.5TB of material), 123456 ranks first, password fourth and qwerty123 fifth; an older list quoted just as often is the SplashData ranking published yearly since 2011. The two lists use different methods from year to year, so do not merge them into a claim about perennial chart toppers. I take one conclusion from them: those strings are guaranteed to be in the attacker's first dictionary. And the first move after obtaining a store is not brute force but a dictionary run with mutation rules: swap a for @, o for 0, capitalise the first letter and append a year. Keyboard sequences such as Abc@2024 and qazwsx are among the first candidates, and they hit several orders of magnitude faster than exhaustive search. What made my six digits dangerous was not the length of six but that it was a date: birthdays, employee numbers, the last digits of a phone number, a year of joining, all structures people love to write and attackers find easy to assemble.
The other risk is reuse. When a small or mid-sized site is breached, account and password pairs leak together, and scripts try the same pair against major email providers, payment services, cloud consoles and file storage. What usually falls is not the main account but some old account the owner forgot about. That is exactly how I lost my way in.
3. What I actually redid
- Make a list first: email, cloud provider, payment, social, internal systems, and old services that still have access. Sort by what a breach would cost, not by how often you use them. Doing this turned up seven or eight accounts I had created only to download a single file back then, so I closed or disabled them.
- Replace the password on every line. I did this in Random Password Generator, with length fixed at 16 and uppercase, lowercase, digits and symbols all enabled. For the few I have to type by hand in a terminal, I tick the option to exclude look-alike characters and drop
0/Oand1/l/I(the option covers those five characters). The part I would not compromise on is the random source: passwords must come from a cryptographically secure random generator, which in a browser meanscrypto.getRandomValues.Math.randomis pseudo-random; once the seed is recovered, the whole sequence before and after can be recomputed, so generating passwords with it is the same as not randomising at all. Running locally and not sending anything to a backend only covers transport. Whether the random source is sound is a separate question, and both have to hold. - Save each one into the password manager right away, not into a notes app and not into a chat window. I keep a single master password, generated longer still, written on paper in a drawer, on the condition that it never appears anywhere except the login screen.
- Close ports like 22 and 3389 to the public internet and switch to keys or a tunnel. This has nothing to do with password strength, but it is the step that actually stops the bleeding.
4. Do not treat a strength score as a guarantee
Assessment tools look at character composition, entropy and theoretical brute-force time. They measure randomness; they do not know whether your password is someone's birthday, and they do not know whether it is already sitting in a breach corpus. So I go in two steps: first check the score and entropy with Password Strength to make sure the structure is not obviously weak, then ask myself separately whether anyone who knows me could assemble this password. Conversely, a random 16-character password can score as strong and still drop to the weakest tier the moment it is reused on two sites.
- What really sets the security boundary is how fast the other side can check hashes. Users cannot control that, so the only fallback is not reusing passwords, which is also why the durations in the first section have to be read with their assumptions attached.
- Without supporting measures, forced periodic changes push people toward increments like
Abc@2024toAbc@2025, which are easier to guess. Avoiding mandatory rotation is not my personal preference: NIST SP 800-63B recommends exactly this, no periodic forced change without evidence of compromise. My current practice is to change only when there is a sign of a leak. - Two-factor authentication ranks above stretching a password from 16 to 24 characters.
- Personal-information passwords built from a phone number, employee number or the part of an email address before the @ must be ruled out entirely; a colleague can guess them by working backwards.
5. Common questions
Q: Is longer always better, and is there any point going past 20 characters?
For an ordinary account, 16 mixed random characters is enough, and the extra length mostly buys peace of mind. The effort is better spent on avoiding reuse and turning on two-factor authentication.
Q: Do I have to add symbols?
Symbols enlarge the character set, so at equal length they really do cost more time. But if adding them forces you to rely on a pattern and start reusing, the trade is a net loss. Length and randomness come first.
Q: Can a password generated in a web page be taken by the server?
I checked how these tools work: the password is produced in the browser, nothing is sent to a backend and nothing is logged, so the generation cannot be overheard. What matters more is that the random source is cryptographically secure; a reversible pseudo-random generator like Math.random does not count. The real risk starts after generation, in how you store it. Pasting it into a chat window, an email or a screenshot is what turns it into a leak.
Q: How do I cope with a dozen accounts I cannot possibly memorise?
Do not try to memorise them. The password manager stores each random password and you remember one master password. Autofill covers most everyday logins, but for payment and cloud consoles I suggest typing manually so a credential never lands on the wrong domain.
Q: How would I know my password has already leaked?
Two kinds of signal: logins from unusual locations and unexpected verification code requests in your inbox, and public breach lookup services. If an alert arrives, change the email password first, because that account is the reset path for everything else.
The lesson from that scanned server was not that passwords should be complex. It was that attackers always take the weakest door, and the weakest door is usually one you have forgotten still exists. Listing accounts, sorting them by what losing each one would cost, and starting from the first line is far more practical than vowing to use 24 characters from now on.