Dynamically adjusting the hash count is an interesting idea (though I would strongly recommend using a better measure of entropy than password length alone), bu

Dynamically adjusting the hash count is an interesting idea (though I would strongly recommend using a better measure of entropy than password length alone), but I'm not really sure how this answers my concerns - as attackers will generally have at least one known username-password combination, it is trivial to recover the pepper if the database is not strongly enough hashed. If you use high password complexity as an excuse to lower hash counts, you only make it easier for attackers to recover the pepper. It also doesn't really address the root failure of password policies, in that many users will simply pad passwords with required characters and/or be more likely reuse a single password that fulfills standard requirements. Comparison against lists of compromised/vulnerable passwords remain a better way to ensure complexity, preferably in combination with a password strength meter.