Password security guide
How to Create a Strong Password
A strong password is unique to one account, long enough, difficult to predict, generated without personal patterns and protected by the rest of the sign-in system.
The short answer: generate, store and never reuse
For an ordinary account, use a reputable password manager to generate a random password that meets the service rules. A practical default is 16 to 20 characters when the service accepts it. Save it to the correct account entry, enable MFA or a passkey, and protect the recovery email and phone.
This process solves three common failures together. Random generation avoids human patterns, a manager makes long values usable, and uniqueness contains damage when one service is breached. A password is not strong in practice if it is pasted into phishing pages, reused elsewhere or recoverable through a weak mailbox.
How long should a strong password be?
Length expands the possible search space when characters are selected independently. NIST SP 800-63B requires a minimum of 15 characters for a password used as the only authentication factor and at least eight when it is part of multi-factor authentication. Verifiers should accept at least 64 characters. Those are verifier requirements, not a claim that every 15-character password is equally strong.
A random 16-character password from a broad pool is very different from a 20-character quotation. Attackers try leaked passwords, words, dates, keyboard paths and common mutations before exhaustive random guesses. Choose a longer generated value for important accounts when compatibility permits. See the detailed length guide for 12 versus 16 versus 20 characters.
Why uniqueness matters as much as complexity
Credential stuffing takes a username and password exposed at one service and tests the same pair elsewhere. The attacker does not need to calculate entropy or crack a hash. If a unique password leaks, the incident is largely contained to that service. If a reused password leaks, email, shopping, social and financial accounts may all be at risk.
Do not use a shared password pattern such as a base word plus the service name. Once one example leaks, the pattern can reveal the others. A password manager should create an unrelated value for every account.
Random generation beats personal password recipes
People are poor random sources. Capitalizing the first letter, replacing a with @, adding the current year or ending with an exclamation mark are familiar transformations. They may satisfy a composition rule without adding much guessing resistance.
A cryptographic generator chooses from a documented pool using operating-system or browser randomness. This site uses browser Web Crypto and rejection sampling. When a service requires upper case, lower case, numbers and symbols, the tool can require each group without putting them in fixed positions.
Password examples: structure, not credentials to copy
| Example structure | Problem or use |
|---|---|
CompanyName2026! | Predictable public words and date. Do not use. |
| Four self-chosen related words | Human theme and ordering are guessable. |
| Six independently selected random words | Useful when a long memorable credential is needed. |
| 20 independently selected random characters | Good for an account stored in a password manager. |
Never copy a published example. Anything displayed in a guide is known and should be treated as invalid.
Should you use symbols and composition rules?
Use the target service policy. A randomly selected symbol increases the pool, but no particular character makes a password safe. Composition rules can lead people toward predictable patterns and unnecessary resets. NIST recommends blocklists of common and compromised values rather than forcing mixtures of character types.
Compatibility is practical, not theoretical. Some systems restrict spaces, Unicode, leading characters or maximum length. Generate for the documented policy and store the exact accepted result.
Store strong passwords safely
A password manager encrypts a credential vault and fills credentials on matching sites. Evaluate update history, security architecture, export and recovery options, device support and the provider response to incidents. Protect the vault with a unique master passphrase and strong MFA.
Do not keep an unencrypted password spreadsheet in cloud storage, reuse a browser note, or email credentials to yourself. If an organization must share access, use a managed sharing feature with individual accounts, audit logs and revocation rather than a group chat.
Use MFA and passkeys to protect the account
MFA adds another requirement after a password. An authenticator app, security key or platform passkey is generally more resistant to interception than SMS, although available methods depend on the service. Store recovery codes offline and enroll more than one safe recovery method before removing the old one.
A passkey replaces the shared password for supported sign-ins with a public-key credential bound to the legitimate service origin. It can reduce phishing and reuse risk, but device access and account recovery remain important. Compare the models in Password vs Passkey.
When should you change a password?
Change it promptly when it has been disclosed, phished, reused, shared with the wrong person, found in a breach, or exposed by malware. Also change vendor defaults and temporary credentials. Do not rotate a strong unique password on an arbitrary schedule unless policy requires it or compromise evidence exists.
After compromise, sign out other sessions, remove unknown devices and app access, review MFA and recovery settings, and change every account that reused or derived from the credential. Start with email and the password manager because they can reset other accounts.
Strong password checklist
- Unique to one account.
- Generated randomly or made from independently selected random words.
- Long enough for the risk and accepted by the service.
- Stored in a reputable password manager.
- Protected with MFA or replaced by a passkey where suitable.
- Backed by secure recovery information.
- Changed after evidence of exposure, not merely to satisfy a calendar.
How to apply the advice on restrictive websites
Some services allow only a small set of symbols, reject spaces or cap length. Start with the longest compatible generated value. If the form rejects it, change the generator policy and create a new password rather than manually deleting characters from an existing result. Store the accepted version only after a successful sign-out and sign-in test.
When a site has a short maximum, uniqueness and MFA become even more important. Do not compensate by creating an undocumented personal recipe that will spread to other accounts.
Strong passwords for families and teams
Every person should have an individual account where the service permits it. Shared logins hide responsibility and make offboarding difficult. For household access, use a manager collection or family-sharing feature. For work, use managed sharing, roles, audit logs and central revocation.
Do not place a shared password in a document that anyone can copy indefinitely. Rotate credentials after membership changes and review recovery ownership.