[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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:


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] and provide at least the minimum security strength specified in the latest revision of SP 800-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.

Nabil Alsharif.
The cryptography mailing list
cryptography AT metzdowd.com