Password Management Best Practices

Reviewed by Marcus Chen, CISSP

Credential compromise was involved in 49% of breaches in the 2023 Verizon DBIR, and password reuse is the primary enabler. Password managers that enforce unique credentials per system, combined with breach detection monitoring, reduce credential-based attack success rates more effectively than any complexity policy. Traditional complexity rules are security theater that compliance frameworks require but that provide minimal real-world protection.

Passwords are not a good authentication mechanism. They're vulnerable to guessing, brute force, interception, reuse, and social engineering. And yet, passwords remain foundational to virtually every system because alternatives that work at scale are still uncommon. Rather than hoping passwords disappear, the pragmatic approach is understanding how to work with passwords in a way that minimizes the damage when they're compromised—because they will be compromised.

The fundamental password problem is not strength. It's reuse. An organization cannot prevent employees from reusing passwords across systems, and when an attacker acquires a password dump from a breach at one company, they immediately try those same credentials against other systems. Your organization's strong password policy is irrelevant if an employee uses that same strong password at five other companies, one of which gets breached, and that password ends up in a public database that attackers use in credential stuffing attacks against your organization.

Understanding this reality changes how you approach password management. It means accepting that you cannot rely on password strength alone. It means deploying technology that reduces reuse. It means building systems that can detect when an employee's credentials appear in a breach at another organization. And it means ensuring that your password storage and recovery mechanisms are strong enough to survive compromise.

What Password Strength Actually Means

Length matters more than complexity, and research from NIST (SP 800-63B) confirms that long passphrases produce higher entropy than traditional complexity requirements while being easier for users to remember.—a measure of how many possible combinations an attacker would need to try before guessing a password. A six-character numeric PIN has very low entropy. A 128-bit truly random string has very high entropy. But humans can't remember or create truly random passwords, which creates a practical problem: what password characteristics actually reduce risk in real environments where humans are involved.

Most organizations have traditionally mandated password complexity: uppercase and lowercase letters, numbers, symbols, minimum length, and regular changes. The assumption is that complex passwords are harder to guess. This makes intuitive sense and feels like security. But research has repeatedly shown that these requirements are not particularly effective at preventing compromise. Users respond to complexity requirements by choosing predictable passwords—adding a capital letter and a number to a dictionary word, followed by the current month. These passwords look complex but have much lower entropy than the requirements suggest.

What actually matters is length. A passphrase—a longer string of random dictionary words, like "correct horse battery staple"—has much higher entropy than most complex passwords because of the length, even though it uses only lowercase letters. Studies show that users who are told to create longer passphrases create stronger passwords than users told to follow complexity rules, and they're more likely to remember the passphrase without writing it down.

This matters because most organizations still mandate traditional complexity rules. You're probably operating under a policy that requires uppercase, lowercase, numbers, and symbols. This policy feels secure. It's security theater. It forces users to create passwords they can't remember, which leads to writing them down or reusing them across systems. The better approach—tell users to create a long passphrase and let them use whatever characters they want—is simpler, more effective, and less frustrating. But it requires rethinking a policy that's been in place for two decades.

If you're building a password policy from scratch, mandate length and prohibit reuse. Make passwords at least 12 characters, forbid them from being reused across previous passwords, and don't require them to change on a fixed schedule unless your compliance framework specifically requires it. If you're operating within an existing policy that mandates complexity, understand that the policy is about compliance with a standard more than it is about actual security.

The Human Password Problem and Why Managers Exist

Password managers eliminate the reuse problem by generating and storing unique credentials for every system, reducing the blast radius of any single breach to zero for your organization. A person can reasonably remember three to five strong passwords. But a typical employee at a mid-sized organization has access to far more systems: email, cloud applications, SaaS platforms, development tools, HR systems, accounting systems, content management platforms. Without a way to manage all those passwords, humans do what's practical: they reuse the same few passwords across all systems.

This reuse is the core problem. When an attacker obtains a password dump from a breach, the first thing they try is using those credentials against other systems. If an employee uses the same password for your systems as they use for LinkedIn, and LinkedIn gets breached, attackers will try that password against your organization. If the password is reused, the attacker gains access. If every system requires a unique password, the breached credential is useless against your organization.

Password managers solve this by automating the memory problem. The manager stores passwords in an encrypted vault, generates strong unique passwords for each system, and fills in the passwords when the user needs to authenticate. A user needs to remember only one strong password—the password to the vault. Every other password is generated by the manager and stored securely.

This approach eliminates reuse because each system gets a unique password. It also means that a breach at one company doesn't compromise credentials at other companies. An attacker obtains one password from a dump and tries it against your organization, but it fails because that's not the password the employee uses for your systems.

For organizations, deploying a password manager is transformative. Instead of fighting human nature, you acknowledge it. You accept that users cannot manage dozens of unique strong passwords manually. You provide technology that does the job. Adoption rates are typically high because the user experience is actually better than trying to remember or manage passwords manually.

Credential Reuse and Breach Detection

Hundreds of millions of credentials appear in public breach databases every year, and attackers immediately test these against other systems through automated credential stuffing. When those external systems get breached—and hundreds of millions of credentials are dumped in breaches every year—attackers add those credentials to databases and use them in credential stuffing attacks. Your employees' email addresses are probably in at least one public breach database. Attackers will try those credentials against your systems.

Modern organizations address this through breach alerting. When a credential appears in a public breach database, the organization is notified and can take action. This might mean forcing a password change for that account, investigating whether the credentials were actually used to compromise your systems, or notifying the employee that their password has been compromised and they should change it everywhere they use it.

Breach alerting requires monitoring—subscribing to databases of breached credentials and regularly checking whether your organization's user accounts appear in them. Tools exist that automate this. The insight is simple: assume your employees' credentials will appear in breaches external to your organization. Detect when that happens. React quickly. This approach acknowledges that the password problem extends far beyond your organization and that you need to monitor and respond to threats coming from external breaches.

Default Credentials and Embedded Secrets

Default and hardcoded credentials are among the easiest vulnerabilities for attackers to exploit, and the 2023 Verizon DBIR found that default credentials were a factor in 21% of web application attacks. default credentials and hardcoded secrets. Many systems ship with default passwords—think of the default admin credentials for a router or a database. These are typically weak and well-known. In production environments, these defaults should be changed immediately. They frequently are not.

Similarly, developers often embed credentials in code—database passwords, API keys, authentication tokens—to make development easier. These hardcoded secrets are intended to be temporary but frequently make it into production. A developer checks in credentials as a stopgap while troubleshooting an issue, intends to remove them later, and forgets. The code gets deployed. Credentials are now in production systems and source code repositories.

These are operational discipline problems more than password problems. The solution is not a better password policy but operational processes: requiring that default credentials be changed as part of system deployment, automating credential rotation so that embedded credentials have limited lifetime, scanning code repositories for accidentally committed secrets, and using secret management systems that store and rotate credentials rather than embedding them in code.

If you're managing systems, understand that default and embedded credentials are critical vulnerabilities that will be found and exploited if they exist. Assume that every default credential has been tried against your systems. Assume that every repository will eventually be scanned for embedded secrets. Build the assumption into your deployment and development processes.

Password Storage and Hashing

Your hashing algorithm determines whether a stolen password database is cracked in minutes or remains protected for centuries. whether they can crack passwords quickly or whether it would take centuries of computation.

Hashing is a one-way encryption—you cannot reverse it to recover the original password. When a user logs in, the system hashes the password they entered and compares it to the hashed password in the database. If they match, the user is authenticated. If an attacker steals the hashed password database, they cannot determine the original password by reversing the hash. They must try guessing the original password, hashing it, and comparing to the stolen hash.

Weak hashing algorithms like MD5 or SHA1 can be brute-forced quickly. A modern computer can try billions of combinations per second against weak hashes. Modern algorithms like bcrypt or Argon2 are intentionally slow. They're designed to use significant CPU time and memory to hash a single password, which means an attacker trying to crack hashes must also use significant time and resources for each attempt. The computational cost of cracking passwords hashed with bcrypt is so high that trying to brute-force them is impractical.

Additionally, proper hashing uses salting—adding a random value to the password before hashing. Salting prevents attackers from using rainbow tables—precomputed hashes of common passwords. If the salt is random for each password, the rainbow tables don't work and the attacker must compute hashes individually.

If you're responsible for systems that store passwords, use bcrypt, scrypt, or Argon2 for hashing. Never use MD5 or SHA1 for password storage. Never store passwords in plain text. These are not subjective preferences—they're basic standards that you must follow. If your systems don't meet these standards, fix them.

Password Reset and Account Recovery

The password reset process is frequently the weakest link in authentication, and attackers prefer attacking recovery mechanisms over primary authentication because security questions and help desk verification are easier to defeat. When a user forgets their password and needs to reset it, the system needs to verify their identity somehow. Many organizations use security questions: "What's the name of your first pet?" The problem is that these questions often have weak answers that are easily guessed or found on social media.

A stronger approach uses email verification. To reset a password, the user must click a link sent to their registered email address. This assumes the email account is secure. It's not foolproof—email accounts can be compromised—but it's better than security questions. The best approach combines email verification with additional factors if available, like requiring an MFA code during password reset.

Account lockout policies matter as well. If an attacker is attempting to reset an account, they're essentially trying to regain access. Policies that lock an account after failed authentication attempts, or that rate-limit password reset attempts, make these attacks harder. The tradeoff is user frustration: if a legitimate user forgets their password and is locked out after three attempts, they can't reset it and must contact support.

These mechanisms are worth getting right because account recovery is a vector that attackers actively exploit. If your password reset process is weaker than your authentication process—which it often is—an attacker will prefer attacking the reset mechanism to attacking the primary authentication.

The Practical Reality

Effective password security addresses how passwords actually fail in practice: reuse, weak storage, poor recovery, and the absence of a second factor. That means accepting that password reuse will happen and defending against it through breach alerting and password managers. It means accepting that humans cannot remember dozens of unique complex passwords and deploying technology to manage that burden. It means accepting that passwords alone are insufficient and implementing MFA, which is infinitely more important than password strength. It means building password storage and recovery processes that can survive compromise.

Most importantly, it means accepting that password policy—the rules about length and complexity and expiration—is largely theater. These policies exist because compliance frameworks require them, and they make organizations feel like they're addressing the problem. The actual defenses against password compromise are fundamentally different: using password managers to enforce uniqueness, detecting when credentials appear in external breaches, implementing MFA so that a compromised password doesn't grant access, and ensuring that your systems hash and store passwords in ways that survive compromise.

If you're implementing password strategy for your organization, focus your effort there. The policy can follow the compliance requirements and feel like security. The real security comes from the mechanisms that address how passwords actually fail in practice.

Frequently Asked Questions

Should we still require password changes every 90 days?

No. NIST SP 800-63B explicitly recommends against mandatory periodic password changes unless there is evidence of compromise. Forced rotation leads to predictable password patterns (adding a number, changing the month) that reduce effective entropy. Require changes only on evidence of compromise or credential exposure.

What password length should we require?

Require a minimum of 12 characters with no maximum length restriction. NIST research shows that longer passphrases produce substantially higher entropy than short complex passwords. A 16-character passphrase with no special character requirements is stronger than an 8-character password with uppercase, lowercase, numbers, and symbols.

How do we get employees to actually use a password manager?

Deploy it as a company-provided tool, pre-configure it for all corporate systems, and make it easier than the alternative. Organizations that deploy enterprise password managers see adoption rates above 80% within 90 days when the tool is integrated into the authentication flow and supported by IT.

Are biometric passwords (fingerprint, face) more secure?

Biometrics are authentication factors, not passwords. They work best as one factor in multi-factor authentication. The limitation is that biometrics cannot be changed if compromised. A stolen fingerprint template is permanent, unlike a password that can be reset. Use biometrics as a convenience factor alongside something the user knows or has.

What should we do if employee credentials appear in a breach database?

Force an immediate password reset for the affected account and investigate whether the credentials were used to access your systems. Deploy automated breach monitoring so this happens within hours, not weeks. The IBM 2023 Cost of a Data Breach report found that breaches identified within 200 days cost $3.93 million less on average than those taking longer.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about password management practices and technologies as of its publication date. Password security standards, threat landscapes, and best practices evolve continuously. Consult qualified cybersecurity professionals for guidance specific to your organization.