As the question puts it: is there a test that can be done or a software that can be used, that is able to provide numbers/data to prove how secure a password hashing is? Say for example that I want to compare the security between using "phpass' portable hashes" and hashes made from "PBKDF2 using SHA3-512 as the HMAC" or hashes from using Argon2.

One way I've seen used in a paper, is they used Hashcat to compare the time it would take to crack the hash of SHA-1 and SHA-3. But since Hashcat doesn't seem to support "PBKDF2 with SHA-3 as the HMAC" nor Argon2, I don't think I can use it the same way as in that paper for anytime I want to compare a method/scheme/algorithm that Hashcat doesn't support.

So what I'm looking for is a test/software that can be used to show "whether a password hashing scheme? method? algorithm? is better than an other one" to someone who isn't really into cryptography...

  • $\begingroup$ It's unclear what "PBKDF2 using SHA3-512 as the HMAC" is, because HMAC needs a block size. That's 64 bytes for SHA-1 and SHA-256, 128 bytes for SHA-512, but that's not clear for SHA3-512. PBKDF2 never was good, and is best forgotten, use Argon2 or if unavailable scrypt, or even bcrypt wich offer much better protection for comparable cost of legitimate use. Of course, parameterization (number of rounds for PBKDF2) plays a significant role. $\endgroup$
    – fgrieu
    Commented Jun 17, 2022 at 13:32
  • 1
    $\begingroup$ @fgrieu: for SHA3-512, the block size (also known as the rate) would be 72 bytes. Of course, HMAC is designed to work around a problem with Merkle-Damgård ciphers that SHA3 doesn't share, so it's unclear why you'd use it... $\endgroup$
    – poncho
    Commented Jun 17, 2022 at 21:09
  • 1
    $\begingroup$ @fgrieu I'll clarify in my question that using "PBKDF2 using SHA3-512 as the HMAC" is just an example. I'm not looking for what's the preferred already well-known method to hash passwords, but what I can do to show to 'someone not really into cryptography' that "this preferred way of password hashing" is better than for example, phpass' portable hashes. By the way, are there more suited tags I can use? Maybe that caused the misunderstanding... $\endgroup$ Commented Jun 18, 2022 at 3:20
  • 1
    $\begingroup$ @fgrieu SHA-3's MAC is KMAC. Since SHA-3 has resistance to the length extension attacks, the prefix construction is easy and secure. $\endgroup$
    – kelalaka
    Commented Jun 18, 2022 at 10:49

1 Answer 1


Password hashing or more generally key stretching takes as input low-entropy key and public salt, process that thru a public, purposely slow, pseudo-random function, yielding a hash/derived key that is ultimately stored for comparison or used as key. The goal is to make it hard for adversaries to enumerate the likely/possible values of the input, apply the public function, and test if the output behaves as the actually used one.

The ideal "numbers/data to prove how secure a password hashing is" would be: how much money is an adversary expected to spend to compute the outputs for some large number of inputs.

A first approach is the computational cost of the function for the legitimate user, measured e.g. in millisecond of CPU time. In practice that's controlled by an iteration count. Increasing iteration count increases the computational cost of the function, for both legitimate user and attackers. When we compare two instances differing only by iteration count, the higher the iteration count, the better the protection. And past a certain threshold, that's proportionally, because the cost for attackers is dominated by this iterated operation. The iteration count is thus set to as high as possible in a given context; e.g. without causing a significant delay for end users, or investment/electricity/VM metering cost for a server operator. It's then possible to measure the computational cost for legitimate user, in e.g. millisecond of CPU time.

This computational cost for legitimate user metric is useful, if only because said cost limits how high legitimate users can set the iteration count. However hat gives no useful idea about cost for an attacker, thus no useful idea about the protection offered; an thus does not allow meaningful comparison between different password hashing functions.

To illustrate how dramatic the difference can be between cost for legitimate user and cost for attacker, I'll take a hashing function in common use: PBKDF2-HMAC-SHA-256. It has a cost parameter $c$, which controls how many times it's iterated $U_{j+1}:=\operatorname{HMAC-SHA-256}(\mathrm{Password},U_j)$. One such iteration requires two rounds of SHA-256. $c$ is typically $10^3$ to $10^7$. On the PC I'm using right now, $10^5$ iterations uses an energy of like¹ $5\,J$. But common bitcoin mining hardware is advertised for $3.8\cdot10^{-6}J$ (soon $2.1\cdot10^{-6}J$) for the same number of SHA-256. Thus an hypothetical adversary using state of the art ASIC would hash one or two million passwords for the same energy cost as one for a legitimate user. For \$100 of electricity at 10¢ per kW⋅h, and PBKDF2-HMAC-SHA-256 at $c=10^5$, they would test $10^{15}$ passwords. That is

  • every combination of 8 characters among 75: letters upper and lowercase, digits, and 13 special characters.
  • an average of 100 passwords generated per the XKCD password strategy, which is much better than what most passwords are.

Even if state-level adversaries are likely far from that efficiency (because they invest in repurposable hardware like FPGA), it's safe to say they can crack most passwords people remember given it's PBKDF2-anything and salt, with $c=10^5$.

Arguably, the most important metric thus is: relative efficiency of legitimate user compared to what state of the art can achieve. I propose to take the base-2 log of that quantity, in absolute value. We want that as close to 0 as possible. We've seen that for PBKDF-HMAC-SHA-256 as on my PC, we are at about 20. Importantly, that depends a lot on the optimization of the implementation legitimate users use.

The best general technique to lower that quantity is: make sure computing the function requires a lot of RAM, and accesses to that, and can't be optimized. That is, a memory-hard iterated hasing function. That's the strategy pioneered by scrypt, and used by it's modern successor Argon2.

(to be continued, hopefully).

¹ I'm timing PBKDF2-HMAC-SHA-256 as bundled in python 3.10.5 with

import timeit;print(timeit.timeit('import hashlib;hashlib.pbkdf2_hmac("sha256", b"tst", b"abc", 100000, dklen=16)',number=100))

yielding 5.1s and make the power consumption 100W.

  • $\begingroup$ Thank you very much for your answer! Measuring the power consumption slipped my mind. Do you happen to have any references or sources that can further back up this answer? The method done in Comparison of the Power Consumption of the 2nd Round SHA-3 Candidates seems similar enough, though I'm not sure just how much I can replicate it for password hashing or key-stretching... and the more references/sources the better... $\endgroup$ Commented Jun 21, 2022 at 8:35
  • 1
    $\begingroup$ @LearningBakpao: this is a complex subject, and my answer is only half-done. There is useful material linked there, including the Argon 2 paper. Also read the scrypt paper linked in the answer. $\endgroup$
    – fgrieu
    Commented Jun 21, 2022 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.