Hi Team,
I have the kick start file where my root password is store like
# Root password rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/ # System authorization information auth --useshadow --passalgo=sha512
Is there any way to decry pt the password and get it as plain text.
I know single user mode works but my case it in remote site.
Thanks,
Jegadeesh
2015-03-31 8:08 GMT+03:00 Jegadeesh Kumar jegasmile@gmail.com:
Hi Team,
I have the kick start file where my root password is store like
# Root password rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/ # System authorization information auth --useshadow --passalgo=sha512
Is there any way to decry pt the password and get it as plain text.
Well, you could bruteforce sha512 hashed password or use dictionary attack against it.
No realistic way to encrypt hashed password.
-- Eero
On Mar 30, 2015, at 11:37 PM, Eero Volotinen eero.volotinen@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
On 03/31/2015 06:08 PM, Jegadeesh Kumar wrote:
I have the kick start file where my root password is store like
# Root password rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/ # System authorization information auth --useshadow --passalgo=sha512
Is there any way to decry pt the password and get it as plain text.
No, it's a one-way hash. In other words it's possible to encrypt a password into the hash, but you cannot turn it back into a password. The way this works is when you login the password you provide is encrypted and the encrypted version is compared against this string to see if they match.
Peter
On 03/31/2015 12:08 AM, Jegadeesh Kumar wrote: <>
Is there any way to decry pt the password and get it as plain text.
yes. but not inexpensive.
from this group;
you will find;
http://www.openwall.com/john/pro/linux/
and a shell script for using;
http://linuxshellaccount.blogspot.com/2008/01/simple-linux-and-unix-password...
hth.
On Mar 30, 2015, at 11:08 PM, Jegadeesh Kumar jegasmile@gmail.com wrote:
# Root password rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/ # System authorization information auth --useshadow --passalgo=sha512
Those two settings are inconsistent. The $1 at the beginning of that crypt(3) string means it’s an MD5 password.
Is there any way to decry pt the password and get it as plain text.
Do you have any idea how long the original password is, and what “alphabet” it uses? (i.e. Lowercase only, or mixed case? Does it also include numbers and symbols?)
If so, this page will give you some idea of what it will take to crack that password:
https://www.grc.com/haystack.htm
You are probably looking at something like the middle scenario, “offline fast attack,” since you probably don’t have a massive server farm to attack this with, and that page was probably written with MD5 attacks in mind, given that it was created in 2011.
Warren Young wrote:
On Mar 30, 2015, at 11:08 PM, Jegadeesh Kumar jegasmile@gmail.com wrote:
# Root password rootpw --iscrypted $1$1SItJOAg$UM9n7lRFK1/OCs./rgQtQ/ # System authorization information auth --useshadow --passalgo=sha512
Those two settings are inconsistent. The $1 at the beginning of that crypt(3) string means it’s an MD5 password.
Is there any way to decry pt the password and get it as plain text.
<snip>
This is all interesting, but I've got one dumb question: why do you need to decrypt it?
mark
On Wed, April 1, 2015 11:09 am, Andrew Holway wrote:
This is all interesting, but I've got one dumb question: why do you need to decrypt it?
In the UK we have a law which give you the right to remain silent; so as not to incriminate yourself. I think in the US its known as "taking the fifth".
Indeed.
But I for one can deduce the answer, assuming the OP knows everything I know or more (sorry for abbr.; Original Poster I had to say). Here is my speculation:
One can easily replace root password hash in kickstart. The only scenarios that that is not enough I can imagine are:
1. OP has to deal with machine kickstarted before and had no ability (or wants to avoid it to leave no track that that is done) to boot the machine in a single user mode and edit shadow file
2. OP was able to get kickstart file content (the hash actually), _has_ to use it, but is not able to edit it (or editing is not an option due to some other consideration)
3. This is somebody's else kickstart password, but I do exclude immediately it as as a result one can imagine a [cyber]criminal action here which I don't expect from anyone ;-)
That said, I just have to mention it once again. It is really advisable to always change root password that came from kickstart file before even new system goes live.
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Wed, April 1, 2015 11:09 am, Andrew Holway wrote:
This is all interesting, but I've got one dumb question: why do you need to decrypt it?
In the UK we have a law which give you the right to remain silent; so as not to incriminate yourself. I think in the US its known as "taking the fifth".
Indeed.
But I for one can deduce the answer, assuming the OP knows everything I know or more (sorry for abbr.; Original Poster I had to say). Here is my speculation:
<snip> *sigh*
I was deliberately avoiding the reasons I could think of, so that the OP might tell us without the witness being lead....
mark
On Wed, Apr 01, 2015 at 06:09:01PM +0200, Andrew Holway wrote:
In the UK we have a law which give you the right to remain silent; so as not to incriminate yourself. I think in the US its known as "taking the fifth".
The UK RIPA act requires you to hand over decryption keys upon presentation of the correct paperwork.
On Wed, 2015-04-01 at 18:09 +0200, Andrew Holway wrote:
This is all interesting, but I've got one dumb question: why do you need to decrypt it?
In the UK we have a law which give you the right to remain silent; so as not to incriminate yourself. I think in the US its known as "taking the fifth".
English law states silence, in response to an arrest caution, can be used against the arrested person at their criminal trial. The English system permits prosecutors to mislead and confuse the jury and to blatantly lie about the defendant. In those circumstances has an alleged "Right not to self-incriminate" any practical usefulness ?
Follow-ups, if any, off the list, please.
-
Always Learning -
Andrew Holway -
Eero Volotinen -
g -
Jegadeesh Kumar -
m.roth＠5-cent.us -
Peter -
Stephen Harris -
Valeri Galtsev -
Warren Young