What Makes a Good Password Manager? Passwords and Secrets in Your App and Team

A software product keeps passwords and secrets in three places, and each needs a different fix. Your team’s logins belong in a shared password manager with two-factor login. Your users’ passwords should be hashed with a slow algorithm such as Argon2id, under rules that changed in 2025, or handed to a sign-in provider so you don’t store them at all. Your app’s secrets, meaning API keys, database passwords and signing keys, belong in a secrets manager and never in the code. This guide covers all three.

What a good password manager does for a team

For one person, almost any reputable password manager will do. For a team running a product, look for these:

• Shared vaults with access per person, so a contractor sees the staging logins and not the payment provider.
• Two-factor login to the manager itself, and single sign-on if your company uses it.
• An activity log that shows who opened or changed which entry.
• Clean offboarding. When someone leaves, you remove them in one place and see which shared passwords they could read, so you know what to change.
• A password generator, and warnings about reused or breached passwords.
• Autofill in browsers and on phones, so people use it every day.
• Export in a standard format, so you can move to another tool later.

Passwords saved in one person’s browser fail the offboarding test: when that person leaves, nobody knows what they had.

The logins that need the most care

A handful of accounts can take the whole product down: the cloud account’s root login, the domain registrar, the payment provider, the code host, and the App Store and Google Play accounts. Treat them differently from everyday logins. Verizon’s 2026 Data Breach Investigations Report says software vulnerabilities have now overtaken stolen passwords as the top way attackers get in, but stolen logins are still among the most common causes of breaches.

• Register them to the company, with a company email address.
• Protect them with the strongest second factor the service offers, such as a hardware security key or a passkey. Where you can choose, avoid codes sent by text message.
• Use the owner login only for the few tasks that need it, and give daily work its own accounts with fewer rights.
• Keep the recovery codes in the password manager’s most restricted vault.

Your users’ passwords: the rules changed in 2025

In July 2025 NIST, the US standards body, published the final version of its digital identity guideline, SP 800-63B-4. Its password rules differ from what many sign-up forms still ask for.

Rule	What the guideline says
Minimum length	At least 15 characters when the password is the only factor; at least 8 when it is part of multi-factor login
Maximum length	Should allow at least 64 characters
Composition rules	No other rules, such as forcing symbols or numbers
Forced periodic changes	Not allowed; force a change only when there is evidence of compromise
Blocklist	Check new passwords against common, expected and compromised ones
Password managers	Must allow password managers and autofill; should allow paste

Many older guides, including an earlier article on this blog, told teams to force regular password changes. The current guideline says not to.

For the blocklist, a service such as Pwned Passwords lets you check a password against known breaches without sending it: your server hashes it and sends only the first five characters of the hash.

How you store passwords matters as much as the rules. The OWASP Password Storage Cheat Sheet recommends Argon2id with at least 19 MiB of memory, 2 iterations and 1 degree of parallelism. If Argon2id isn’t available, use scrypt. Bcrypt is for older systems only, with a work factor of 10 or more and its 72-byte password limit in mind, and PBKDF2 with 600,000 iterations or more where FIPS-140 compliance is required.

Or don’t store passwords at all

Often the safest password is one your app never sees. A sign-in provider handles storage, resets and two-factor login for you, and your code only checks the result.

Subflare, a lead scoring product we built, uses AWS Cognito for sign-in, and new clients receive generated login details, so the team never handles passwords people choose themselves. Daisy’s Guide lets couples sign up with email, Google or Apple, with two-step login.

Your app’s secrets

Secrets are the keys your app uses to talk to other systems: database passwords, payment and email API keys, cloud credentials, webhook signing secrets. If one leaks, someone else can act as your app.

Leaks are common, and leaked keys stay valid for years. GitGuardian’s State of Secrets Sprawl 2026 counted 28,649,024 new secrets exposed in public GitHub commits in 2025, 34% more than the year before. It also found that 64% of the valid secrets it detected in 2022 still worked four years later. That second number is why rotation is on the list below.

The OWASP Secrets Management Cheat Sheet sets out the main rules:

• Never hardcode secrets in source code or in Docker build files. Inject them at deploy time from a secrets manager or a mounted file.
• Be careful with environment variables. They can leak through logs, crash dumps and other processes.
• Give each person and service access to only the secrets it needs. Engineers shouldn’t be able to read every secret.
• Log who read or used each secret, and when.
• Rotate secrets regularly and automatically, so a stolen one works only for a short time.
• Scan for secrets on developers’ machines before commits and in the build pipeline.

If your code is on GitHub, its push protection blocks pushes that contain credentials. It is on by default for users pushing to public repositories, but for a repository an admin has to switch it on.

When HealthyNikah, a UK matchmaking app, came to us, the old code had no safe place for keys. As part of the rebuild we moved the backend to the client’s own AWS account and fixed what the security audit found. The HealthyNikah case study has the full story.

When a secret leaks

Revoke it first and investigate second. OWASP’s advice is to revoke the exposed secret at once, issue a new one, remove it from code and logs, and check who had access. Deleting the file from the repository isn’t enough, because the secret stays in the history. Our incident response runbook covers the rest of the first hour.

When someone leaves the team

• Remove them from the password manager, single sign-on and the code host.
• Change every shared password they could read.
• Rotate the API keys and deploy keys they used.
• Move any account registered to their personal email into the company’s name.

That last step matters most when an agency or a freelancer leaves. Our code audit starts there: for a fixed $3,500 in 5 working days, it lists every account the product depends on and whose name it is in, then ranks the security problems with the worst first.

What we would do

1. Pick a team password manager that meets the checklist above, and move every shared login into it this week.
2. Turn on two-factor login for email, the code host, the cloud account, the domain registrar and the payment provider.
3. Use a sign-in provider for your users. If you store passwords yourself, follow the NIST table and hash with Argon2id.
4. Move every secret out of the code and into your cloud’s secrets manager, and turn on secret scanning.
5. Keep a list of every secret: where it is used, who can read it and how to rotate it.
6. Check that every account the product depends on is in the company’s name.

These steps are part of a wider set of security controls to build in from day one.

Building something new? Write sign-in, secrets storage and offboarding into the scope as their own user stories. To see what your idea costs to build with that work included, run it through our project estimate: you confirm each story, and every hour in the budget traces back to one you kept.

FAQ

What makes a good password manager for a business?

Shared vaults with access per person, two-factor login to the manager, an activity log, simple offboarding that shows which passwords a departing person could read, breach warnings, autofill on every device and export in a standard format.

Should we force users to change their passwords regularly?

No. NIST SP 800-63B-4 says services shall not require periodic password changes. Force a change only when there is evidence that a password has been compromised.

What is the minimum password length?

Under NIST SP 800-63B-4, at least 15 characters when the password is the only login factor, and at least 8 when it is used with another factor. Allow at least 64 characters, and don’t require symbols or numbers.

How should my app store passwords?

Hash them with Argon2id, using at least 19 MiB of memory, 2 iterations and 1 degree of parallelism, as the OWASP Password Storage Cheat Sheet recommends. Better still, let a sign-in provider store them so your app never sees them.

Are environment variables safe for API keys?

They are better than keys in the code, but OWASP discourages them because they can leak through logs and crash dumps. A secrets manager that injects keys at deploy time is safer.