I am migrating a Classic ASP website to new hardware and it uses Pbkdf2 to create password hashes.
The old server has a 4-core Intel Xeon X3220 CPU and 4GB RAM (Windows Server 2003), while the new server has dual 10-core Xeon E5-2630 v4 CPUs and 64GB RAM (Windows Server 2012 R2).
Testing with 1,000 random passwords, the old server creates 1,000 hashes in ~70 seconds, but the new, more powerful server, takes ~80 seconds.
Shouldn't the new server be much faster at this process? I was hoping to increase the hash iterations on the new hardware.
Here's the function that creates the hash:
Public Function HashPassword(ByVal sPassword, ByRef sSalt) Dim oCrypt Dim oPrng Dim sEntropy Dim sCharset Dim sHashAlgorithm Dim iHashIterations Dim sOutputBitLength Dim sEncoding sCharset = "utf-8" sHashAlgorithm = "sha256" iHashIterations = 10000 sOutputBitLength = 192 sEncoding = "base64" Set oCrypt = Server.CreateObject("Chilkat_9_5_0.Crypt2") If oCrypt.UnlockComponent(Application("chiklatunlockcode")) <> 1 Then Set oCrypt = Nothing HashPassword = "" Response.Write("Crypt2 Unlock Error") Response.End() End If ' Set encoding mode (for salt generation) to same as that of the returned key as they must match; oCrypt.EncodingMode = sEncoding ' Create random 16-byte (128-bit) salt using PRNG Set oPrng = Server.CreateObject("Chilkat_9_5_0.Prng") sEntropy = oPrng.GetEntropy(32, sEncoding) oPrng.AddEntropy sEntropy, sEncoding sSalt = (oPrng.GenRandom(16 ,sEncoding)) Set oPrng = Nothing ' generate and return key from Pbkdf2; return of salt is through the ByRef salt parameterc HashPassword = oCrypt.Pbkdf2(sPassword, sCharset, sHashAlgorithm, sSalt, iHashIterations, sOutputBitLength, sEncoding) Set oCrypt = Nothing End Function
I think you've missed the entire point, or rather the purpose of functions such as PBKDF2. The intent of the algorithm is to keep the computation slow to prevent brute-force attacks.
In cryptography, PBKDF1 and PBKDF2 (Password-Based Key Derivation Function 2) are key derivation functions with a sliding computational cost, aimed to reduce the vulnerability of encrypted keys to brute force attacks.
Trying to make it go faster goes against the entire intent of the algorithm. You'll notice there is an iHashIterations argument -- this is the number of hash iterations to compute. Change it from 10000 to 5000, and it goes twice as fast. Want to make it really fast? Change it to 2. But that defeats the entire purpose of the algorithm. You're actually working to make your system insecure.
Thanks for the response, however I appreciate that Pbkdf2 is supposed to slow the computation down for brute-force attacks.
As hardware improves over time, the speed of brute-force attacks is increased, especially off-line attacks on compromised data, so the general advice to account for this is that iterations is also increased over time.
On faster hardware I expected the algorithm performance to naturally increase, just like any other computations would, and that I would need to increase the iterations to account for this, therefore making the system more secure.
Based on my timings, it appears that this implementation of Pbkdf2 keeps the delay commensurate with iterations, especially as the performance on the two vastly different hardware platforms is broadly similar. Is that correct?