[Cryptography] Possible reason why password usage rules are such a mess

Nabil Alsharif blit32 at circuitsofimagination.com
Mon Nov 23 15:21:48 EST 2020


Hi

On 11/20/20 1:57 PM, Arnold Reinhold via cryptography wrote:
> 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 https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-matt_weir-sudhir_aggarwal-cracking_passwords.pdf
>
> And a more recent story https://hackernoon.com/20-hours-18-and-11-million-passwords-cracked-c4513f61fdb1
>
> 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:
>
> https://www.onlinehashcrack.com/tools-benchmark-hashcat-gtx-1080-ti-1070-ti-rtx-2080-ti-rtx-3090.php
>
> 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.

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:

> 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 [SP 800-90Ar1]
> <https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-90Ar1> and
> provide at least the minimum security strength specified in the latest
> revision of SP 800-131A
> <https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-131A> (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.
>

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.

Thanks,
Nabil Alsharif.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201123/d820297d/attachment.htm>


More information about the cryptography mailing list