CentOS - Feb 2014 - Password hash rounds solved - important security implications

A member of the scientific-linux-users at fnal.gov wrote:
On 01/14/2014 04:19 PM, George Shaffer wrote:
> > If anyone has gotten password hash rounds using hash_rounds_min and
> > hash_rounds_max in libuser.conf, or the counter part in login.defs 
> > (SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS), to work on any RHEL
related
> > distribution, I would appreciate knowing how you did it, because this
does
> > not seem to work as the documentation I've found says it should. I
know
> > the crypt method must be SHA256 or SHA512.
> 
> This has an additional PAM setting that might be pertinent.
> http://blog.myconan.net/posts/3567
Thank you. This is just what I needed. The hash rounds control is now working,
mostly. At the maximum rounds setting it took 14 to 19 seconds depending on
which PC I was on. I needed to bring the delay down to around 1 to 2 seconds.

It's not working as the documentation describes. With both libuser.conf and
login.defs set to ranges of 900000000 to 999000000 and pam.d/password-auth-ac
set to 900000000, the actual rounds on both SL and CentOS were 9999999 or <
1.1% of what it should have been. This doesn't matter to me, as I need it
faster, not slower. In pam.d/ both password-auth and system-auth are links to
password-auth-ac and system-auth-ac respectively. These files clearly state:
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.

which is sometimes, but not always true. If a rounds number remains in both
password-auth and system-auth after authconfig --updateall is run, that is the
number which is used, except the maximum value is 9999999 and not 999999999. I
got 1000000 to work on both SL 6.3 and CentOS 5.10, and authentication took just
about 2 seconds on both systems. On CentOS 5.10 I could find no PAM
documentation anywhere that described the rounds option; I had to rely entirely
on the brief blog brought to my attention by the S-L-users list member. On SL
6.3 the PAM rounds option is documented in man 8 pam_unix. If I'm reading
this correctly, the proper file to edit would be /etc/pam.d/login where the line
"password    sufficient    pam_unix.so sha512 rounds=1000000 shadow nullok
try_first_pass use_authtok" should be added.


Password hash rounds control seems to be almost unused. I got no responses in
the CentOS 5 Security forum or on the general CentOS email list.

People do not seem to understand how important this can be to password security.
According to the oclHashcat (hashcat.net) documentation on the fastest GPU
enabled PC they have tested, they get 797 million CPS (cracks per second)
against SHA512. If the super fast PC is compared to the single CPU PC with no
GPU, using the only algorithm common to all tests (NTLM), there is a speed
difference of 1981 times. This suggests roughly 400,000 CPS against SHA512 on
the single CPU PC they tested. (Each hashing algorithm interacts differently
with the various hardware test configurations, so using one algorithm to
estimate how another will perform on a different machine is only a crude
estimate. Below, the numbers are discussed like reliable estimates, but until
empirical evidence establishes the actual rates in a specific situation, none
are reliable.)

The Hashcat single CPU machine has an AMD Phenom II X6 1090T clocked at 3.8 GHz.
The test times of single CPU PCs without GPUs are relevant because the GPU
enabled, oclHashcat, cannot run a simple dictionary word list with no
transformations. oclHashcat must have, brute force characters added to either or
both ends of the words in a list. To run a list of the 10,000 most common
passwords, without transformations, you need to use the single CPU Hashcat or
the deprecated GPU oclHashcat-plus. It seems there is no efficient way to make
use of a massively parallel architecture using a simple word list.

oclHashcat also cannot process the "Rule-based Attack" which
corresponds with the transformations found in John the Ripper. Again one must
use the single CPU Hashcat or the deprecated oclHashcat-plus. So, oclHashcat is
blindingly fast with a GPU on brute force and related attacks but cannot process
the most obvious dictionary or do the most productive transformations of a
dictionary containing real words and names. The most productive transformation
is checking the first character, and only the first character, for upper and
lower case, in combination with appending 1, 2, or 3 digits to the end of the
word. The third digit would be very low yield compared to the first, but still
very high compared to any pure brute force attack. If these issues are
indicative of a problem that does not fit well with a massively parallel
architecture, and not limitations of the oclHashcat developers, there are
significant implications for password security.

Simply put, password hash round controls can be used to deny crackers most of
the space where modified dictionary attacks get the weak, but not blatantly bad,
passwords. If Hashcat is run against the default configuration of SHA512 on my
desktop PC, roughly 240,000 CPS seems plausible. Unless there is a fast
implementation of SHA512, the use of 1,000,000 hash rounds, which takes about 2
seconds to authenticate on an AMD Phenom II X6 1090T, should slow the the
cracking process down to about 0.5 CPS, or more than a five orders of magnitude
difference. A simple list of the 10,000 most common passwords might take perhaps
5.5 hours with a million round SHA512, rather than about 5 seconds against the
default SHA512.

On most systems, the top 10,000 passwords, should get 70% to 95% of the
passwords. Five hours isn't very long but it's a lot longer than 5
seconds. Where the slowdown really hurts the cracker is in the subsequent runs
of reduced efficiency but still productive dictionaries and transformations. One
option might be to use the next next million most common passwords. A PC 4 times
as fast as the Hashcat single CPU PC should approximate a current, high end PC,
and run about 4 CPS against the million rounds SHA512. The million words takes
just under 70 hours; that should crack another few percent. Next might be a
small 35,000 word dictionary of common names and and mostly common words. The
most productive transformations should be both upper and lower case on the first
letter, plus 1 through 3 digits appended to the end. That's 77.7 million
test passwords taking just about 225 days.

If a PC is 4 times faster than the Hashcat test PC against the standard
configurations of SHA512, that is 1.6 million CPS. The million rounds
configuration takes 228 days for the first 78.7 million test passwords; the
default SHA512 configuration is 49 seconds. One is doable but takes commitment,
patience, and resources; the other is trivial. Each successive dictionary plus
transformations tends to get larger with a lower positive result rate. Any sane
person will stop earlier, with regards to how many dictionaries are used, when
they see they are faced with an abnormally high number of hash rounds; it shows
up very plainly in the hash, just after the "$6$" as
"rounds=1000000".

A two second delay for logins or su's may seem like a lot, but we wait
longer many times a day for various computer events, none of which get us the
added security that a million rounds on a sound hashing algorithm with good
salts gets us. A one to two second delay is quite perceptible. If this is not
acceptable, then a target time between 0.1 and 0.2 seconds should not be
noticeable, but still imposes a massive penalty on the cracker. This is a
security freebie. For a fairly minor configuration change, system administrators
can role back cracking times 2 or more decades. They only need to determine what
is an acceptable delay for authentication on their systems, and how may hash
rounds it takes to get in that range. Decent 8 character passwords become almost
uncrackable.

George Shaffer