[CentOS] How to decrypt rootpassword form kickstart file

[Warren Young]

On Mar 30, 2015, at 11:37 PM, Eero Volotinen <eero.volotinen at iki.fi> wrote:
> 
> Well, you could bruteforce sha512 hashed password or use dictionary attack
> against it.

The sad thing is that dictionary attacks still work.  Just a few months ago on this very mailing list, we had a big battle over whether the default password rules should be tightened down to preclude them.  <shakes head>

> No realistic way to encrypt hashed password.

Of course you mean “decrypt,” but there’s a bigger mistake in that statement.

Simply hashing the password *does* allow for a realistic attack: rainbow tables.  This uses a large array of computers to calculate the hash for every entry in a given set of passwords.

Check out this list of freely-downloadable rainbow tables:

  http://project-rainbowcrack.com/table.htm

It tells you that if you’ve been using a 10-character all-lowercase password with possibly a digit or two, it can probably be cracked instantly by referring to this rainbow table.  *If*, that is, it was stored in a password database that simply hashes the password to protect it.

The single simplest way to defeat rainbow tables is by salting the password, which Unix systems have done since approximately forever.[1]  Linux copied that practice from the beginning.

The reason rainbow tables exist is that there are still password systems today that ignore this 37-year-old lesson.  A lot of web sites store their passwords this way, which is why the standard advice is to never reuse the same password at more than one site, even if they claim to “encrypt” your password.

Once you step beyond MD5 passwords on CentOS to SHA-256 or SHA-512, you have the option of using a random number of hashing rounds, greatly increasing the difficulty of producing a rainbow table and the space required to hold it:

- SHA-512 takes about 3x the space of SHA-1, which produced about 2 TiB of tables on the page I linked above.

- The salt is 12 bits of randomness, multiplying the number of required tables by 4,096.

- The man pages are unclear, but I believe the default range of random rounds in CentOS 6 & 7 is 1,000 to 5,000.  If, so, this multiplies the resource requirements again by 4,000.[2]

All together, the storage space is about 94 EiB, which is approximately equal to the amount of information interchanged across the world’s telecommunications networks in a year.[3]  The difficulty of cracking a single SHA-512 password as done on CentOS 7 is roughly as difficult as building a second Internet, just as big as the first, without reusing any of the current Internet resources.

Given that the current Internet takes a few billion people to run, mostly in their spare time, you probably need several million full-time staffers to run your CrackNet.  

Most of those staffers will be spending their time just replacing failed components.  Given that the MTBF on the electromechanical components of the CrackNet is only in the low millions of hours, having billions of them means you can expect a continuous stream of failed hard drives and fans.

If you’re still worried, you can edit /etc/libuser.conf, increasing hash_rounds_max.  It can go up to 999,999,999, which means you can increase the CrackNet scenario’s difficulty by up to 250,000 times.

If you find yourself in control of a quarter million CrackNets, you are probably a superintelligent energy form living in the post-Singularity world, by which point all this worry about password security will have become a rather low-priority concern.




------

[1] This 1978 paper by Ken Thompson and Robert Morris talks about salted passwords in Unix: http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps

As far as I can tell, this first appeared in UNIX V7 (1979).


[2] If my understanding of this point is wrong, the OS can be configured to do this.

While you’re thinking about this, you could changing the default range to 5,000 to 10,000, for example, which would break even the ridiculous CrackNet scenario at the cost of only ~4x longer password verification time, on average.  It would probably still run in under a second, which is fast enough for human-interactive tests.


[3] Source: http://en.wikipedia.org/wiki/Petabyte