Password Managers and 2FA: Security Hygiene for Developers

Developers think of “being hacked” as something that happens to other people — people who reuse Summer2024! everywhere and click links in fake delivery emails. Meanwhile the actual data says: developers are among the most targeted individuals on the internet, precisely because our accounts unlock more than our own stuff. Your GitHub account guards code that ships to users. Your npm token can poison a supply chain. Your cloud console key can spin up a crypto-mining fleet with your credit card attached.

The industry’s biggest breaches of the past few years have repeatedly traced back to a single developer’s compromised credentials or session. So this is the security-hygiene baseline for people like us — practical, opinionated, and doable in a weekend.

The foundation: a password manager, used correctly

The math is unforgiving: you have hundreds of accounts, humans can memorize roughly one good password, and credential leaks happen weekly somewhere. When passwords are reused, one breached fitness app becomes your email, which becomes everything (password reset flows all lead through email).

A password manager fixes the entire class of problem: every account gets a unique, random, never-memorized password; you memorize exactly one strong passphrase (four-plus random words — stapler-borrow-vivid-canyon beats P@ssw0rd2026! in both entropy and typability); the manager autofills the rest.

Solid choices in 2026: 1Password (best UX, family/team features), Bitwarden (open source, generous free tier, self-hostable), Proton Pass, or KeePassXC (fully offline, maximum control). Choosing between the good options matters far less than adopting one today and doing the full migration: run its audit tool, hunt down every reused password, rotate them. Tedious for an afternoon, then done forever.

Two developer-specific bonuses. First, the built-in random generation makes throwaway service accounts painless. Second, browser-integrated managers only autofill on the exact registered domain — a quiet anti-phishing check that has saved more people than they know: if the manager won’t fill, look at that URL again.

Not all 2FA is created equal

Second factors exist because passwords leak. But the hierarchy matters enormously:

Click to enlarge

The line that matters is phishing resistance. A TOTP code protects you when your password leaks, but a convincing fake login page captures your password and your code in real time — this exact attack (often via a proxy kit) is how most “we had 2FA!” breaches happen. FIDO2 hardware keys and passkeys are immune: the cryptographic exchange is bound to the real domain, so there is simply nothing to type into a fake site.

Practical upgrade path: enable 2FA everywhere (TOTP minimum), then move your critical tier — email, GitHub, cloud providers, package registries, password manager itself — to passkeys or a hardware key (a pair of YubiKeys, one as backup, runs ~€60). Print the recovery codes for those accounts and store them somewhere physical; the most common self-inflicted lockout is “phone died, TOTP gone, recovery codes never saved.”

Passkeys: the passwordless present

The industry’s decades-long attempt to kill passwords finally shipped. Passkeys are cryptographic key pairs synced through your password manager or platform: the site holds a public key, your device signs a challenge after biometric/PIN unlock, and there’s no shared secret to steal, reuse or phish.

The developer angle: GitHub, Google, Microsoft, AWS and most major services support them; password managers sync them across devices (solving the “new phone” problem); and users sign in faster with them than with passwords. Adopt them personally on every account that offers them. And if you build products with login: WebAuthn libraries are mature — offering passkeys is now table stakes rather than innovation.

Passwords won’t vanish overnight, so the transitional stance is: passkeys where possible, manager-generated unique passwords elsewhere, phishing-resistant 2FA on everything critical.

Developer-specific hygiene: secrets are credentials too

Your personal accounts are half the story. The other half is the credentials your code uses:

• Never commit secrets. Every “temporary” hardcoded API key is one git push from immortality — remember that removing a secret from history isn’t enough once it was public; rotate it. Install a pre-commit scanner (gitleaks) so the mistake gets caught before it exists; GitHub’s push protection is a good safety net, not a substitute.
• .env files are a floor, not a ceiling. Fine locally (and in .gitignore, verified). But shared via Slack DM, they’re just distributed plaintext. Teams should graduate to a secret manager — 1Password’s developer tooling, Doppler, Vault, or your cloud’s native store — with secrets injected at runtime, not written down.
• Prefer short-lived credentials. Fine-grained tokens with expiry dates on GitHub/npm; OIDC-federated deploy credentials in CI instead of long-lived keys pasted into settings. A leaked token that expired last Tuesday is a non-event.
• Audit the blast radius quarterly: ~/.aws/credentials, ~/.npmrc, ~/.ssh/, active tokens in GitHub settings, OAuth apps you authorized in 2023. Revoke ruthlessly; recreate the rare one you actually needed.
• Lock down the machine itself: full-disk encryption on (FileVault/BitLocker/LUKS — laptops get stolen), OS updates automatic, and be honest about curl | bash and unvetted npm installs — supply-chain attacks target exactly our reflexes. AI-agent users: agents inherit your shell’s credentials; scope what they can reach.

If you work remotely, treat this as professional equipment maintenance — our remote work and salaries overview notes that security posture is increasingly part of what employers assume seniors bring. It’s also a hiring signal: portfolio projects that handle secrets correctly (see our portfolio guide) quietly announce competence.

The weekend checklist

1. Install a password manager; migrate the top-20 accounts; schedule the long tail. (2h)
2. Rotate everything its audit flags as reused or breached. (1h)
3. Passkeys or hardware keys on email, GitHub, cloud, registry, the manager itself. (1h)
4. Save recovery codes physically. (15 min)
5. Install gitleaks pre-commit; scan your repos for committed secrets; rotate any found. (1h)
6. Revoke stale tokens and OAuth grants; set expiries on new ones. (30 min)
7. Verify full-disk encryption on every machine. (10 min)

Click to enlarge

Frequently Asked Questions

Isn’t a password manager a single point of failure? It concentrates risk, yes — into one target you can actually defend properly (one very strong passphrase, phishing-resistant 2FA, a vendor whose entire business is defending it) instead of two hundred targets you demonstrably can’t. The zero-knowledge architecture reputable managers use means even a breach of the vendor yields only encrypted blobs without your master passphrase. The alternative — human-memorable, reused passwords — is a guaranteed failure distributed everywhere. Concentrated defensible risk beats distributed guaranteed risk.

What if I lose my hardware key or my phone with the authenticator? This is why the setup steps include redundancy on purpose: register two hardware keys (one stays home), keep passkeys synced through your manager rather than trapped on one device, and store printed recovery codes for the critical accounts somewhere physical. Do those three things and any single loss — phone in a river, key through a washing machine — is an inconvenience, not a catastrophe.

Is the browser’s built-in password manager good enough? It’s vastly better than reuse, and for low-stakes personal use, fine. Dedicated managers earn their place for developers specifically: cross-browser and CLI access, secure notes and SSH-key storage, item sharing for teams, breach monitoring, and (1Password, Bitwarden) developer tooling for injecting secrets into local environments — the pattern that replaces plaintext .env sharing.

Do I really need this if I’m just a hobbyist? Your GitHub account can push code to projects others install; your email resets every password you own; your cloud free tier has your card attached. The “just a hobbyist” threat model stopped existing around the time supply-chain attacks started targeting maintainers of tiny packages. The weekend checklist costs six hours once — less than recovering a single hijacked account.

Final Thoughts

Security advice fails when it’s abstract, so here’s the concrete version: a password manager ends credential reuse, passkeys and hardware keys end phishing, short-lived scoped tokens end the immortal-leak problem, and a pre-commit scanner ends the accidental commit. Four tools, one weekend, and the attacks that actually compromise developers — not cinematic zero-days, but boring credential theft — mostly stop applying to you.

We hold keys to systems other people depend on. Treating those keys with professional care isn’t paranoia; it’s the same craftsmanship we claim to apply to everything else we ship.