Because if your password manager is compromised, so are all of the passphrases stored in it. So what would the point, then, be of using different ones?

So because a password manager is one-stop shopping (something that I'm subconsciously uneasy about, to be sure), it's pointless to use different passphrases, one of the major selling points of password managers.

So to protect against that, don't use a password manager. Which means that you're more likely to re-use passphrases, because lots of them are hard to remember and keep straight. So breaking one gets access to many others.

My head spins.

I was originally going to post something along these lines, but then I realized that this argument doesn't work the same in this particular context, and the parent isn't necessarily arguing against password stores in general. Sure, it might be better (in the sense of not concentrating your risk to a single file) to have a strong (importantly, private) scheme for creating passwords (say, based on the site and account name). But if you're restricted to some inane restrictions ("6-10 alphanumeric characters"), then there's not really a strong argument against a password manager in this case.

Sure, in general, you want to avoid password reuse to isolate password compromises / security breaches (some companies are still storing passwords in plaintext in 2016, ugh). But in this case, we're talking about private keys that should never leave your local machine. If those are compromised (even passphrase-protected), then it's not inconceivable to think that your password store might also be compromised.

> he parent isn't necessarily arguing against password stores in general.

Yeah, reliazed that, my post was just my "logical" progression.

The compromise I use is to break the cycle: Use a password manager to generate strong passwords (and different ones, because breaches happen), and use a hardware token-based password for the manager itself. At least that's the compromise I'm comfortable with.