Increasing iteration count for the PBKDF2 password hasher

[Shaheed Haque]

Hi,

As happens from time-to-time, I see the 5.1 alpha recently announced has increased the iteration count for the PBKDF2 password hasher (from 720k to 870k), and the putative release notes for 5.2 mention a further increase (to 1M).

I assume this iteration count has something to do with the noticeable time it takes to run User.set_password()? Is there something that can be done to mitigate any further increase in the execution time of .set_password(), or am I barking up the wrong tree?

Thanks, Shaheed

[Mike Dewhirst]

My understanding is the intention is to make brute force attacks more expensive for the attacker.

Don't know whether there might be a better way.

Thanks, Shaheed

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHAc2jcETxAtMbHfnD1GQFVgWwR8ABOAy%3DjaRuhRW7mQhnOxeQ%40mail.gmail.com.

-- 
We recommend signal.org

Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Your
email software can handle signing.

[Faisal Mahmood]

Hi Shaheed,

You're on the right track. lets deep dive in further.

 The increasing iteration count in PBKDF2 for Django's password hasher is indeed related to the time it takes to run User.set_password(). Here's a breakdown of the situation and potential solutions:

Why the Increase?

• Security: Modern password hashing algorithms like PBKDF2 are designed to be computationally expensive. This makes it more difficult for attackers to crack passwords using brute-force methods.
• Evolving Threats: As computing power increases, so do the capabilities of attackers. Increasing the iteration count makes password hashing more secure in the face of these advancements.

Mitigating Execution Time:

While security is paramount, you might want to consider some options to manage execution time:

1. Tune Based on Needs:
   • Evaluate your security requirements. If you don't deal with highly sensitive data, you might consider a slightly lower iteration count (within reason). However, prioritize security for critical applications.
2. Hardware Upgrade:
   • If feasible, consider upgrading your server hardware to handle the increased processing demands. This can be a more sustainable solution for long-term scalability.
3. Asynchronous Tasks:
   • If password hashing is a bottleneck in your application's performance, consider using asynchronous tasks to handle password hashing in the background. This can improve responsiveness for users while the hashing is taking place.

Important Considerations:

• Lowering iteration count significantly weakens security. It's generally not recommended unless absolutely necessary, and even then, do so with great caution.
• Regular Security Updates: Stay updated with Django releases to benefit from security improvements and potential optimizations related to password hashing.

Alternatives (Use with Caution):

• Custom Password Hasher: Consider creating a custom password hasher with a lower iteration count. However, this is a complex approach and requires careful security evaluation to avoid compromising user data. It's generally not recommended unless you have a very specific use case and a deep understanding of password security best practices.

In Conclusion:

The increasing iteration count in Django's password hasher is a trade-off between security and performance. Evaluate your needs and available resources to determine the most suitable approach. Remember, prioritize security for sensitive data, and adjust settings or hardware cautiously to maintain a balance between speed and user experience.

Have a Nice Day Ahead. KEEP CODING