Why the password is still the weak link
You can lock down a server by the book, set up website security, and still lose the account to one weak password. The reason is simple: people reuse passwords. The same one guards email, a shop and a forum — and when the forum is dumped, that password opens the email, and the email opens everything else.
The attack is called credential stuffing: someone takes millions of login-password pairs from old breaches and replays them automatically on other sites. They do not need to hack you — that was already done for them. So password strength is not about being hard to remember; it comes down to two rules: a password must be long and unique to each site.
How passwords leak
A password is rarely 'guessed'. Far more often it leaks in whole databases:
- Service breach — the user database with passwords ends up online. If the passwords were stored badly, they are cracked quickly.
- Phishing — you type the password yourself on a fake page indistinguishable from the real one.
- Malware — stealers harvest browser-saved passwords straight off an infected device.
- Reuse — a leak on one site automatically compromises every other where the same password is used.
The outcome is always the same: the password lands in public databases that already hold hundreds of millions of records. The good news — you can check those same databases to see whether your password has surfaced, and do it safely.
What makes a password strong
Strength is measured not by having a 'special character' but by entropy — the number of options an attacker would have to try. Length raises it far more than exotic symbols: four random words beat a short 'P@ss1!'.
- Length — at least 12–16 characters, more for important accounts.
- Randomness — not a name, date or dictionary word, but genuinely random.
- Uniqueness — a different password per site, so one leak does not open the rest.
Inventing that in your head is pointless. Generate it instead: our password generator creates a long random password right in the browser, cryptographically strong, without sending it anywhere.
How to check a password against breaches
You can check whether a password is in known breaches without revealing it. It works by k-anonymity: the password is hashed in your browser, only the first five characters of the hash go to the server, a list of matches for that prefix comes back, and the match is found locally. The server never sees the password or its full hash.
That is exactly how our password leak check works: it compares the password against the Have I Been Pwned database, storing nothing. If the password shows up in breaches, treat it as compromised and change it everywhere you used it. The same check is worth wiring into your sign-up and password-change forms, to warn users about a weak password before they set it.
Password managers and two-factor authentication
Long, unique passwords cannot be kept in your head — and they do not need to be. A password manager generates, stores and fills them for you; you remember only one master password. It is the only practical way to have a different strong password on every site.
The second layer is two-factor authentication (2FA). Even if the password leaks, the second factor blocks the login. In order of strength: a hardware key or an authenticator app beats SMS codes, which are intercepted through SIM swapping. Turn on 2FA at least for email and banking — those are the accounts that recover all the others.
How to store passwords on the backend (for developers)
If you build a service with sign-up, the responsibility for users' passwords is yours. The base rules are not up for debate:
- Never store passwords in plaintext and never encrypt them reversibly — only an irreversible hash.
- Use slow adaptive functions — bcrypt, scrypt or argon2 — with a per-password salt. Plain SHA-256 will not do: it is too fast and falls to a GPU.
- Check new passwords against breaches at sign-up and change — via the same k-anonymity, without sending the password out.
- Rate-limit login attempts and add 2FA, so a database leak is not instant access.
We bake this into the architecture when we build web apps and SaaS: authentication and secret storage are designed from the start, not bolted on later.
Password security checklist
- A long (12+), random, unique password for every site.
- A password manager instead of memorising and reusing.
- Two-factor authentication wherever it exists — at least email and banking.
- Check important passwords against breaches; on a match, change immediately.
- For developers: argon2/bcrypt with salt, attempt limits, a breach check at sign-up.
FAQ
Is it safe to check a password on someone else's site?
It depends on how the check works. A proper check uses k-anonymity: the password is hashed in your browser and only the first five characters of the hash leave it, so the server never sees the password. Never type a password into a form that sends it in full.
What counts as a strong password in 2026?
Long, random and unique. A practical minimum is 12–16 characters with no dictionary words or personal data, different for each site. Length matters more than 'special characters': a phrase of a few random words beats a short string of symbols.
Do I need a password manager?
Yes — it is the most practical way to have a different strong password everywhere. You remember one master password and the manager creates and fills the rest. The risk of the manager itself being compromised is far lower than the risk of reusing passwords.
Are SMS codes reliable two-factor authentication?
Better than nothing, but weaker than the rest: SMS codes are intercepted via SIM swapping. An authenticator app or a hardware key is stronger. Still, any 2FA is far better than none.
How should I store user passwords on the server?
Only as an irreversible hash via argon2, scrypt or bcrypt with a unique per-password salt — never in plaintext or with reversible encryption. Plain SHA is too fast and unsuitable. Also rate-limit login attempts and offer 2FA.
