Django 6.1 cuts hardened password hashes down to its new 1.5M-iteration default at login

The 50 to 90ms figure, from a benchmark write-up on dev.to, is single-threaded. It was measured on an otherwise idle 4-core container, and it varied with how busy the machine was ^[5]. The author read both defaults off PBKDF2PasswordHasher().iterations in 6.0.9 and 6.1.2 before timing anything ^[2]. The ratio is the portable part. Iterations rose by a factor of 1.25, and the fastest times moved by roughly that much in every run ^[4]. The milliseconds carry over to another fleet only if its cores compute PBKDF2-SHA256 at about that container's speed.

Concurrent logins are where a new choke point would show up, and the post found none ^[15]. On the same box, going from one thread to four raised hashing throughput by 3.5 to 4.0 times ^[16]. Eight threads added almost nothing over four ^[8]. "A login-heavy Django deployment pays for this in CPU headroom, not in a single blocked thread per request," the author wrote ^[9].

The write path is front-loaded. In the post's capture, the hash Django stored after that first login carried a new salt along with the new count ^[10]. So the request checked the password against the stored 1.2M-iteration hash, then ran a full encode at 1.5M. That is about 2.7M iterations in one login, or 2.25 times what a 6.0 login cost ^[17]. Each user pays it once ^[11]. After the deploy, the UPDATE count equals the number of distinct users who sign in, one row each ^[20]. The post does not measure database load from those writes.

Credit where due: upgrading hashes at login is good design. Every active user's hash gets stronger on their next sign-in, and nobody has to write a backfill job ^[14]. The problem is the comparison. Django asks whether the stored iteration count differs from the current default, not whether it is lower ^[12]. The author tested a hash set to 3,000,000 iterations, the kind a security-conscious admin might configure through a custom PASSWORD_HASHERS entry. One login left it at 1,500,000 ^[13]. Hashing time tracked the iteration count in the post's timings ^[4], so that login halved the cost of each offline guess against the hash ^[18].

The admins this catches are, by the post's own description, the security-conscious ones ^[13]. Under the same rule, a deployment whose live hasher still sets 3,000,000 iterations would find the stored and live counts equal and leave the hash alone ^[19]. The downgrade lands on sites where that custom hasher is no longer the live one when 6.1 arrives ^[19].