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

[Arnold Reinhold]

On Thu, 19 Nov 2020 Kent Borg wrote:

> I have a large collection of plain-text passwords that have publicly 
> leaked, where did I get those? That doesn't smell like hashing to me. 

and Sid Spry wrote:

> reversing a properly salted
> password database is only feasible with such a dictionary.
> 
> Brute force in the strictest sense isn't usually tractable.

These two comments do not reflect the current state of the art. For example by 2012 it was possible to try all Windows NTLM eight-character password containing upper- and lower-case letters, digits, and symbols in 5.5 hours using 25 AMD Radeon graphics cards of that era (GPUs have gotten a lot faster since). https://arstechnica.com/information-technology/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/

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.


Several people have commented on the distinction between passswords used to access a resource and those used to derive a cryptographic key.

As Phillip Hallam-Baker wrote (Thu, 19 Nov 2020 05:46):

> This gets me to an oft ignored point: passwords (something that has to be
>> tested against some authority) are completely different from encryption
>> passphrases (which, given ciphertext, can be tested in parallel and at
>> arbitrary speeds).
>> 
> No they aren't. Not in practice because the user has absolutely no control
> over how the password authentication data is going to be stored.

That is why we need some requirement that services that use password authentication disclose the measures they use to store password validation data, or maybe some seal of approval that guarantees the meet some minimum standards, in particular something better than fast hashes, which are no almost useless.

In one way the situation with passwords used to generate cryptographic keys can be better in that a long resource intensive password can be used to process the password. A user can tolerate a delay of a secong or more when opening an encrypted disk drive, for example. 


Arnold Reinhold