A per-user salt doesn't prevent brute forcing bad passwords. The purpose of a per-user salt is to prevent brute forcing all of the passwords simultaneously. Without it, you could just hash a password once and check against all the passwords. With the salt, you have to hash each guess for each user. It certainly increases the work, but with bad passwords, its likely you'll always crack a few in a large dump.

If you have a strong password, a high work factor should prevent brute-forcing it. But really, if it's computationally infeasible to crack a bad password, its also probably computationally infeasible to log in.

In cases like these, even if the risk of password recovery is minimal, a reset should still be forced because the attacks are offline and only become easier as time goes on. Forcing a rotation discourages people from continuing to work on cracking passwords for the next n years until they finally get an interesting account.

Of course, thanks. Guess I wrote that without actually thinking about it. Now, a pepper would prevent brute forcing weak passwords, assuming it wasn't compromised, but that's not relevant here. And regardless I agree with your logic regarding forcing a reset.

No, using bcrypt and per-user salts, forces an attacker to actually do brute-forcing -- not being able to use rainbow tables, or easily test one password against all users. So if they have 2M users, and you can check ~20 passwords per second (what I can do on my workstation with a bcrypt work-factor of 10, single-threaded), it'd take 2M*11/20 seconds ~ 12 days -- to try "username[0-9]?" (e12e, e12e1, e12e2 ... e12e0) against all accounts. And to try any given password, like "Password2015" against all accounts, it'd take 2M/20 seconds ~ 27 hours per guess.

Note that the actual times here are off by a magnitude or two; first they're single-threaded, secondly I happen to have an AMD r9 290 -- and oclhashcat reports 197 hashes/second -- which cuts the time to ~3 hours per guess).