<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi <br>
<br>
<div class="moz-cite-prefix">On 11/20/20 1:57 PM, Arnold Reinhold
via cryptography wrote:<br>
</div>
<blockquote type="cite"
cite="mid:49D73D10-95C5-4C01-A254-3FFDDF43CB8E@me.com">
<pre class="moz-quote-pre" wrap="">Modern cracking software, such as John the Ripper use a variety of modes, including dictionaries, straight brute force and pattern-based searches using word mangling rules. Almost all the passwords in recovered corpuses were from stolen file of hashedd passwords. It’s rare to hear of a hacked firm storing plaintext passwords. Recovery rates from stolen hash files are typically 70 to 80%.
Here is a nice presentation from 2009 <a class="moz-txt-link-freetext" href="https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-matt_weir-sudhir_aggarwal-cracking_passwords.pdf">https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-matt_weir-sudhir_aggarwal-cracking_passwords.pdf</a>
And a more recent story <a class="moz-txt-link-freetext" href="https://hackernoon.com/20-hours-18-and-11-million-passwords-cracked-c4513f61fdb1">https://hackernoon.com/20-hours-18-and-11-million-passwords-cracked-c4513f61fdb1</a>
Not only have GPUs gotten faster, but you can now rent clusters from AWS and the like. Salt helps, of course, by eliminating the possibility of cracking a group of hashes at the same time, but cracking has gotten fast enough that it is still possible to attack them one at a time. And to penetrate an organization, you often only need one recovered password. Resource intensive hashes such as bcrypt, scrypt and pbkdf2 with high iteration count make a bigger difference. Here is a collection of benchmarks using hashcat and modern GPUs:
<a class="moz-txt-link-freetext" href="https://www.onlinehashcrack.com/tools-benchmark-hashcat-gtx-1080-ti-1070-ti-rtx-2080-ti-rtx-3090.php">https://www.onlinehashcrack.com/tools-benchmark-hashcat-gtx-1080-ti-1070-ti-rtx-2080-ti-rtx-3090.php</a>
There are a large number of hashes presented. Note that the hash rate units range from GH/s to MH/s, kH/s and just H/s. A huge range of speeds.
</pre>
</blockquote>
<br>
Although everything Arnold said is true, if the latest NIST
recommendation from the NIST were followed the comparisons above
would become mute. There is this commonly overlooked excerpt from
NIST SP 800-63B:<br>
<br>
<blockquote type="cite">
<p>In addition, verifiers SHOULD perform an additional iteration
of a key derivation function using a salt value that is secret
and known only to the verifier. This salt value, if used, SHALL
be generated by an approved random bit generator <a
href="https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-90Ar1">[SP
800-90Ar1]</a> and provide at least the minimum security
strength specified in the latest revision of <a
href="https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-131A">SP
800-131A</a> (112 bits as of the date of this publication).
The secret salt value SHALL be stored separately from the hashed
memorized secrets (e.g., in a specialized device like a hardware
security module). With this additional iteration, brute-force
attacks on the hashed memorized secrets are impractical as long
as the secret salt value remains secret.</p>
</blockquote>
<br>
The key here is that the salted and hashed password should be hashed
again using a separate salt that is _stored separately than the
hashed secret_. This means if an attacker were able to dump of the
password hashes the attacker could not perform a brute force attack
unless they also got they second, separately stored, salt as well.
This raises the bar significantly since a raw DB dump (i.e. plain
old SQL injection) isn't enough to be able to get the original
passwords any more. <br>
<br>
Thanks,<br>
Nabil Alsharif.<br>
</body>
</html>