This project is read-only.

SimpleMembership/Crypto.HashPassword iterations?

Topics: ASP.NET MVC, ASP.NET Web Pages, General
Aug 7, 2013 at 6:47 PM
I was looking over some of the security stuff in SimpleMembershipProvider, and was rather interested to see that Crypto.HashPassword "only" uses 1,000 iterations (which, to it's credit, references the SDL 5.1, and 1,000 was apparently the original recommendation, back in 2000), even though many people recommend much higher iterations (,, Is there any talk about changing any of these functions to something like scrypt or a much higher number of iterations? Is there a reason (other than backwards compatibility) that it's still doing 1,000 iterations, or is there something about all this that I don't understand?

Aug 24, 2013 at 1:53 AM
Hi Matthew,

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.

The Security StackExchange post linked to ( has some great answers on the subject regarding the various trade-offs and consequences of changing the iterations.

Aug 24, 2013 at 2:15 AM
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.
Aug 25, 2013 at 5:32 PM
Hi Brock,

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.

Aug 25, 2013 at 5:42 PM
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.