Strong Passwords Explained: Length, Entropy, Generators and the Hidden Data in Your Files

Most advice about passwords is a list of rules that nobody explains: add a symbol, change it every 90 days, never reuse it. Some of those rules help and some do not. The good news is that password strength is measurable, and once you see the numbers, the right habits become obvious.

How passwords actually get cracked

Attackers rarely sit there guessing your password one try at a time on a login page. Sites limit attempts, so that approach is slow. The real threats look different.

• Credential stuffing. When a site is breached, the leaked emails and passwords are tried automatically on other sites. If you reuse a password, one breach opens many doors. This is the most common route to account takeover.
• Offline cracking. If an attacker steals a database of password hashes, they can test guesses at enormous speed on their own hardware, with no rate limit. How fast depends on how the site stored the passwords, but billions of guesses per second is plausible against weak hashing.
• Dictionary and pattern attacks. Cracking software tries common passwords, words, names, dates, keyboard walks like “qwerty123” and predictable tweaks such as “P@ssw0rd!”. These are tried long before random guessing.
• Phishing and malware. A fake login page or a keylogger gets the password regardless of strength. Strong passwords do not stop this, which is why multi-factor authentication matters.

So a strong password has two jobs: it must be hard to guess, and it must be unique. A perfect password used on five sites is only as safe as the weakest of the five.

Entropy: strength in bits

Entropy measures unpredictability in bits. Each additional bit doubles the number of guesses needed. For a password chosen randomly from a set of possible characters:

entropy (bits) = length × log2(size of character set)

Common character sets give these amounts per character:

Multiply by length, and you can compare passwords on the same scale:

• 8 random characters from 94: about 52 bits.
• 12 random characters from 94: about 79 bits.
• 16 random lowercase letters: about 75 bits.
• 16 random characters from 94: about 105 bits.

What do the bits mean in real time?

Imagine an attacker with a stolen database protected by a weak, fast hash who can try 10 billion guesses per second. On average they find the answer after trying half the possibilities.

• 52 bits: 2^52 is about 4.5 × 10^15 combinations. At 10^10 guesses per second that is roughly 4.5 × 10^5 seconds, around five days for the full space and half that on average.
• 79 bits: 2^79 is about 6 × 10^23 combinations, which would take on the order of a million years or more at the same speed.

The speed changes dramatically with the hash function. Properly slow hashes, designed for passwords, reduce attacker speeds by orders of magnitude, but you cannot control how a site stores your data. So the safest approach is to make your own passwords strong enough that even weak storage does not matter.

Why length beats complexity

Look at Figure 1 again. Sixteen random lowercase letters (75 bits) beat eight characters from the full keyboard (52 bits) by a wide margin, even though the second looks more “complex”. Each extra character multiplies the possibilities, while adding a symbol class only slightly enlarges the set.

That is why modern guidance has shifted. Forcing people to include an uppercase letter, a number and a symbol mostly produces predictable results such as a capital at the start, a number and an exclamation mark at the end. The NIST digital identity guidelines recommend allowing long passwords and passphrases, screening new passwords against lists of known breached or common ones, and avoiding both composition rules and forced periodic changes unless there is evidence of compromise. Recent revisions also set higher minimum lengths for passwords used on their own.

In practice, the rules to remember are short:

1. Make it long: at least 14 to 16 characters for anything important.
2. Make it random, not clever.
3. Never reuse it.

If you write code that validates passwords, resist the temptation to enforce complicated character rules with a regular expression. Our regex guide shows the lookahead pattern for it, and also explains why length and breach-list checks serve users better.

Passphrases you can remember

Random strings are great for a manager to store. For the few secrets you must remember, such as your computer login or the master password of your password manager, use a passphrase: several random words in a row. The key word is random. A quote or lyric is not random, and attackers know them.

The dice method uses a list of 7,776 words, each assigned a five-dice number. Rolling real dice picks the words, so no human bias creeps in. Each word adds log2(7776) ≈ 12.9 bits:

• 4 words: about 51.7 bits.
• 5 words: about 64.6 bits.
• 6 words: about 77.5 bits.
• 7 words: about 90.5 bits.

Six words is strong for most uses and far easier to type and remember than a 12-character jumble. The Electronic Frontier Foundation publishes word lists and instructions, linked in the references. Separate the words with spaces or hyphens, and consider adding a memorable personal twist you never store anywhere.

Password managers and generators

You cannot remember dozens of unique 16-character passwords, and you should not try. A password manager does the remembering. It creates a random password for each site, stores them in an encrypted vault, and fills them in only on the right domain, which also helps defeat phishing. You need to memorise just one strong master passphrase.

If you need to create a password right now, use a generator that runs locally. The Password Generator creates random passwords in your browser with the length and character options you choose, and does not send them anywhere. Tips:

• Choose 16 characters or more for ordinary accounts, and longer for email, banking and your manager’s vault.
• If a site restricts length or symbols, take the strongest option it allows.
• Copy, paste into your manager, then clear the clipboard.
• Do not email or message passwords to yourself.

For developers, the UUID Generator makes unique identifiers, which are excellent for record IDs. A version 4 UUID has 122 random bits, but treat it as an identifier, not a secret, because it often appears in URLs and logs.

Two-factor authentication and passkeys

Multi-factor authentication adds a second proof beyond the password. Even if your password leaks, an attacker still needs the second factor. Ranking the common types from weakest to strongest:

1. SMS codes. Better than nothing, but vulnerable to SIM swapping and interception.
2. Authenticator app codes. Time-based codes generated on your phone. A solid default.
3. Hardware security keys. Physical devices that also resist phishing, because they verify the website’s address.
4. Passkeys. Cryptographic credentials stored on your device, unlocked with your fingerprint, face or PIN. They are unique per site and cannot be phished or reused, and they are becoming widely supported.

Turn on multi-factor authentication first for your email, since it is the key to resetting everything else, then for banking, cloud storage and social accounts. Keep backup codes somewhere safe and offline.

What websites should do with your password

If you build or run a site, the way you store passwords matters as much as the way users choose them. The rules are firm:

• Never store passwords in plain text, and never encrypt them reversibly.
• Hash them with a slow, purpose-built algorithm such as Argon2, bcrypt or scrypt, with a unique random salt per password. The OWASP password storage cheat sheet lists current recommendations.
• Do not use fast general-purpose hashes like MD5, SHA-1 or a single round of SHA-256 for passwords. They are designed to be quick, which is exactly what an attacker wants.
• Check new passwords against breached-password lists and allow pasting from password managers.
• Rate-limit attempts and support multi-factor authentication.

Fast hashes still have good uses, for example verifying that a downloaded file is intact. The Hash Generator produces checksums for text so you can compare them with the value a publisher lists. A matching hash tells you the file was not corrupted or tampered with in transit.

The other leak: hidden data in files

Passwords are not the only way private information escapes. Files carry metadata, details stored invisibly alongside the content. You share the picture or document, and the metadata goes along for the ride.

Photos and EXIF

Almost every photo from a phone or camera contains EXIF data. Depending on settings, it can include the exact GPS coordinates where the photo was taken, the date and time, the device make and model, lens settings and the software used. A photo of your front door shared as an original file can reveal your home address.

Many large social platforms remove location data from public posts, but not all do, and sending the original file by email, a cloud link or “as a document” in a messaging app can keep it intact. The safest habit is to check before sharing. The EXIF Viewer and Remover shows what a photo contains and strips it, all inside your browser, so your picture is not uploaded anywhere. Compressing and resizing also changes the file; see our image format guide for the details.

Documents

PDFs and Word files store the author name, organisation, creation and edit dates, the software used, and sometimes revision history or comments. Before sending a document externally, inspect it. The PDF Metadata Viewer and the DOCX Metadata Viewer show what is stored, and you can remove it with your editing software’s inspect or export options.

Encoding is not encryption

A frequent security misunderstanding is treating encoding as protection. Base64, for example, turns bytes into text so they travel safely through systems that expect text. Anyone can reverse it instantly. Try it with the Base64 Encoder and Decoder: a “hidden” string becomes readable in a click.

The same is true of JSON Web Tokens. A JWT has three Base64URL-encoded parts, and the header and payload are readable by anyone who holds the token. A signature stops tampering but does not hide the contents. The JWT Decoder demonstrates this. Two practical rules follow:

• Never put secrets such as passwords or API keys in a token payload or in Base64 and call it protected.
• Treat live tokens like passwords. Do not paste real production tokens into tools you do not trust. Tools that run in your browser reduce the risk, but a test token is always the better choice.

A 15-minute security checklist

1. Install a reputable password manager and set a long passphrase as its master password.
2. Change the password on your email account to a unique, random one, and turn on multi-factor authentication there.
3. Do the same for banking, cloud storage and your main social accounts.
4. Replace any password you reuse. Start with the accounts that matter most.
5. Enable passkeys where a site offers them.
6. Check a few recent photos and documents for metadata before you next share them.
7. Save backup codes offline.
8. Check whether your email appears in public breach notification services and change affected passwords.

Frequently asked questions

Related guides and tools

References

1. NIST, Digital Identity Guidelines, SP 800-63B (authentication and lifecycle management). pages.nist.gov
2. OWASP, Password Storage Cheat Sheet. cheatsheetseries.owasp.org
3. Electronic Frontier Foundation, “Dice-generated passphrases”. eff.org/dice
4. Wikipedia, “Password strength” and “Exif”. Password strength · Exif

Time-to-crack figures are rough illustrations that depend heavily on how a service stores passwords and on attacker hardware. This is general guidance, not a guarantee of security.