A Sensible Password Policy for a Small Team: Length, Passphrases and Managers

The United States NIST digital identity guidelines (the SP 800-63B document) moved away from composition rules and forced rotation. In summary: encourage long passwords, allow all printable characters including spaces, permit pasting so that password managers work, check new passwords against lists of known breached passwords, and require a change only when there is evidence of compromise.

The reasoning is practical. Forced symbols produce predictable patterns such as Password1!. Forced rotation produces Password2!, Password3! and so on. People respond to burden by weakening the secret, and attackers know the patterns.

Strength is measured in bits of entropy, where each extra bit doubles the number of guesses an attacker needs. The numbers make the case for length.

• ▸A random 8 character password using all 94 printable ASCII characters has about 52 bits.
• ▸A random 12 character password from the same set has about 79 bits.
• ▸A random 20 character password has about 131 bits, which is far beyond any practical attack.
• ▸A passphrase of four words chosen randomly from a list of 7776 words has about 51 bits, five words about 65 bits and six words about 78 bits.
• ▸Human chosen passwords are much weaker than their length suggests, because people pick predictable words and substitutions.

These figures only hold when the choice is truly random. A phrase from a song or a quote has almost no entropy, however long it looks.

• ▸Every account gets a unique password. Reuse is the main reason one breach becomes ten.
• ▸Use a password manager for everything except the master password, and generate passwords of 16 characters or more with the manager's generator.
• ▸The master password and the device unlock codes are passphrases of five or six random words.
• ▸Turn on multi-factor authentication for email, the password manager, finance, code hosting and admin consoles. Prefer authenticator apps or hardware keys over text messages.
• ▸Change a password only when it is exposed, when someone leaves the team or when a service reports a breach.
• ▸Never send passwords through chat or email. Share access through the manager's sharing feature or by inviting people to the service.

The best policy fails if the tool is hard to use. Pick one manager for the whole team, create shared vaults for shared services, and give everyone thirty minutes of onboarding. Start with the most sensitive accounts first and import the rest over a few weeks. Make a written emergency plan: who can recover the shared vault if its owner is unavailable, and where the recovery codes are stored offline.

A generator must use a cryptographically secure random source. The Strong Password Generator on this site uses the browser's secure random generator, guarantees a mix of the character types you choose, shuffles without bias and works entirely locally. For passwords people must type by hand, such as a Wi-Fi key, choose the option that skips look-alike characters like O and 0, and lengthen the password to make up for the smaller alphabet.

• ▸Isn't one master password a single point of failure? It is a single point, but protected by a long passphrase, multi-factor authentication and encryption. Reusing many weak passwords is a far larger risk.
• ▸Some sites still reject long passwords or spaces. Choose the longest allowed password with the full character mix, and consider telling the vendor.
• ▸People want to memorize passwords. Memorize only the master passphrase and the unlock codes of the devices that hold the manager.