Strong password

How it works

Guessers try common passwords, leaked passwords, and short variations. A strong password fails those lists. Length helps because each extra character multiplies the space of possibilities. Uniqueness helps because a leak at one site should not open mail, banking, or work. Clever substitutions on a short word help much less than people hope. “P@ssw0rd1” is still a famous pattern.

You cannot remember a unique long secret for every site. That is expected. A password manager can generate strong password strings and store them behind one master unlock. The manager is doing the memory job. You are doing the unlock job, the device-lock job, and the “do not type this into a fake page” job.

A site that demands a capital letter, a number, and a symbol is not automatically safer. Composition rules can push people into predictable shapes. Length, uniqueness, and a check against known-breached passwords are the parts that do real work. If a site still requires a mix, satisfy the mix, then keep the secret long and unique anyway.

Generate, suggest, and store

Generate strong password is the honest path: let a manager or a generator built for secrets produce a random string, copy it once into the vault, and do not email it to yourself. Suggest strong password, in a browser, is the same idea when the browser offers a candidate at account creation. Accept it and save it in the manager you actually use, so the suggestion is not trapped in one device.

Do not generate secrets in a search box, a chat, or a shared classroom screen. Those places are for public toys. A password is a secret. If someone can see the generation, it is already a shared password.

Open the manager or the browser’s password saver, not a public generator page. Create a new record for that site. Generate a long random string, or a long random passphrase, and save it there. Turn on the site’s extra sign-in step when it exists.

Keep a recovery path for the vault itself, offline if the product gives you a key. The master unlock should also be strong, and it should not be stored in the same inbox the vault protects. If you can remember only one secret, this is the one, and it should not be reused as a site password.

Strong password examples, and examples to refuse

Strong password examples are patterns, not gifts to reuse. A generated example looks like a long mix of characters with no words, such as a four-block string a manager might draw, for illustration only: xkT7-mQ2p-nL9w-Hv4c. That exact string is now public because it sat in this sentence; do not use it. A passphrase example is several unrelated words with length, not a lyric, not a motto, not your street. After you see an example on a web page, it is only an illustration.

Refuse: a name, team, pet, or birthday, with or without a year on the end. Refuse: keyboard walks such as qwerty or 123456, including “clever” leet versions. Refuse: one favorite phrase on every site, even if it is long.

Accept: a unique generated string stored in a manager. Accept: a unique long passphrase stored in a manager, or memorized only for the vault. If a site has a short maximum length, you are stuck with that ceiling. Make the secret random up to the ceiling, unique, and stored. Then treat that site as fragile: do not reuse that secret, and keep the extra sign-in step on.

A strong password you reuse is a master key you handed to the weakest site. Change a password when a service says it was leaked, when you typed it on a machine you do not trust, or when it was ever shared. Periodic change for its own sake on a unique un-leaked secret is less important than getting off reuse. Start with email, then banking, then the inbox that can reset everything else.