There were a few emails about login times so I figured it warranted a blog post. Strap in, this one goes sideways fast.
Some people noted that the amount of time to log in with a SQL Login in SQL Server 2025 all of a sudden took longer. This is clearly stated in the Docs, though the way it is written is documented is problematic.
First, I’m not sure why this is documented as a “Known Issue” since anyone with enough brain cells to not have Drano* as an aperitif will understand this is expected. Documenting that the password will be hashed a ShitTon™ (or ShitTonne for my readers over the pond) more times will obviously require more cpu time and thus more time to complete the log in. That’s not a known issue, that’s literally the point of hashing something that much so that it’s harder to brute force because of the added time. I’m sure the same people clamoring for more security are the same people who then turn around and complain that more security add complexity and challenges in their environment. My cows are smarter than this.
The other major complaint I personally have is that it seems the documentation page was updated as the original page is missing additional wording, specifically, “and higher CPU utilization”. Refer to the previous paragraph. Why was this needed? It is needed because someone is a complete Dunning–Kruger that shouldn’t need to be anywhere near a computer, let alone one that handles databases for a real life company. Right before that addition, it’s clearly stated, “The increased computational cost of PBKDF2” which makes, “and higher CPU utilization” completely redundant. Are we really at a societal point where we have to tell supposedly professional highly skilled and technical people that higher computational cost means it’s going to take more processing? Color me chartreuse and flabbergasted. You would probably not surprised to learn that someone insisted this was, “a bug”. That’s right. Let that simmer.
To be complete, if you get an etw trace, you’ll see the time is spend in the Windows code that deals with cryptography. If there are better/faster/offloading ways to do this (for example, when processors first started getting dedicated cryptographic functions would could increase their efficiency at doing said items and thus compared to a software only mode would be faster and use less cpu) then it’s up to Windows to implement that based on the callstacks.
If you want to go back to not hashing a ShitTon™ of times for 2025 you can use trace flag 4671. Be forewarned, if you use that in 2022 it’ll turn the new hashing on, whereas on 2025 it’ll turn it off. THAT’s what should have been documented, that’s the weird behavior, it’s not a weird behavior to say doing more cpu bound things will result in more cpu being used. Also, if you’ve already generated a hash but want to turn the TF on/off make sure to generate a new hash after switching the TF.
I know this one seems as I’m being a bit harsh, but I’m not. I genuinely like sharing my knowledge and helping others as I have been helped, passing it on. There is, however, a minimum bar that needs to be met and not being able to understand that more cpu usage means more cpu utilization is beyond the pale. This is basic stuff, if you don’t know this you probably shouldn’t be working on databases or anything IT related for any company.
* Note: I’m not sponsored by anyone… let alone Drano. If you’d like to sponsor me though, I’m listening…