We believe at this time that the right balance for most web applications is to use 1000 iterations. There is a trade-off in security in terms of balancing how many iterations (more is better) and how long it takes to calculate those iterations (more is worse).
If the iterations are increased too much, then a rather trivial DoS attack becomes possible on the server.

We do not have plans at this time to change the iteration count or to make it configurable. However, applications in ASP.NET can always choose to implement their own security functionality if there is a specific application requirement that is not available
in ASP.NET's libraries.

I think that the number needs to be increased but DoS mitigated by proper account lockout for obvious password brute force. With the new ASP.NET Identity system this is a perfect opportunity to accomplish this.

Regarding increasing iterations, it is important to analyze the situation not only from the attacker's perspective but from the server's perspective. An attacker will almost always have far more resources to their disposal than the server (within a given constrained
time period). Even some of today's largest sites can be outmatched by an attacker with a few thousand dollars in their pocket by using any of the available cloud computing platforms for maybe a few hours.

One common problem with account lockouts is that it allows would-be attackers to at least "grief" innocent victims. For example, an attacker who wishes to "annoy" someone could write a simple script that deliberately does an invalid login
every few minutes (or whatever) at the target's favorite web sites, thus preventing the target from ever being able to log in (due to lockout/timeout).

In the new system we are ensuring that scenarios such as 2-factor authentication are possible and we have a working prototype.

Ultimately some of the most important mitigations end up being not the complexity of the password hash, but rather the strength of the password (or pass phrase) itself, using 2-factor auth, auditing login attempts, using HTTPS, or using alternative auth mechanisms
such as certs or smart cards.

Sure, all of those things are true. But even without the hashing iterations, accounts can be (griefed) in many other ways. And also DoS attacks can simply be done with LOIC and attackers don't even have to resort to coding something special for ASP.NET's
password validation scheme.

My point is that we're probably worrying about something that's moot. I just don't think we should give up on proper password storage because we think we're introducing some new attack vector when there are already easier attack vectors. At least an option
should be made available if customers understand these issues and want a different hashing iteration count.