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