shadow file

Hi,

i'd like to see if it's possible to decode this file....
Could someone help me with this ;)
It'd be nice if you posted the decoded version ;)

Thanks!!!

The important line:

root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::

Frank wrote:

> Hi,
>
> i'd like to see if it's possible to decode this file....
> Could someone help me with this ;)
> It'd be nice if you posted the decoded version ;)
>
> Thanks!!!
>
> The important line:
>
> root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::

man 5 shadow
man 3 crypt (or libc infopage)

"It is believed that, given the output of the function, the best way to find
a KEY that will produce that output is to guess values of KEY until the
original value of KEY is found." (libc infopage e0.10)


Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

In comp.os.linux.security Jon Gomez <jon.gomez.04@cnu.edu>:
> Frank wrote:

>> Hi,
>>
>> i'd like to see if it's possible to decode this file....
>> Could someone help me with this ;)
>> It'd be nice if you posted the decoded version ;)

Why? If you can read /etc/shadow you are already root and have no
need.

[..]

>> root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::

> man 5 shadow
> man 3 crypt (or libc infopage)

Looks to me like MD5 password hash, not crypt(), more or less
zero chances reverting it back to the password.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 68: only available on a need to know basis

In article <cp6ki9$je4$05$1@news.t-online.com>, Frank <lol@privacy.net> wrote:
:i'd like to see if it's possible to decode this file....

:root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::

That looks like a standard /etc/shadow line in an OS that allows
the glibc extensions to encrypted passwords. According to

http://unixhelp.ed.ac.uk/CGI/man-cgi?crypt+3

GNU EXTENSION

The glibc2 version of this function has the following additional fea-
tures. If salt is a character string starting with the three charac-
ters "$1$" followed by at most eight characters, and optionally termi-
nated by "$", then instead of using the DES machine, the glibc crypt
function uses an MD5-based algorithm, and outputs up to 34 bytes,
namely "$1$<string>$", where "<string>" stands for the up to 8 charac-
ters following "$1$" in the salt, followed by 22 bytes chosen from the
set [a-zA-Z0-9./]. The entire key is significant here (instead of only
the first 8 bytes).


Thus, in order to decode the password, one would have to find a
password whose MD5 was represented in base64 as xEeZmr2fGEnKjVAxzj/o51 .

MD5 is a 128 bit hash, so brute force would require an
average of 2^127 operations to find a match. That's a lot of
computation.

There are services which are generating pretty much all 8 bit
lowercase + digit plaintexts and using MD5 to encrypt them and
saving the result, but these services don't work with the "salted"
MD5 of shadow password files.

http://passcracking.com/

--
*We* are now the times. -- Wim Wenders (WoD)

> Thus, in order to decode the password, one would have to find a
> password whose MD5 was represented in base64 as xEeZmr2fGEnKjVAxzj/o51 .
>
> MD5 is a 128 bit hash, so brute force would require an
> average of 2^127 operations to find a match. That's a lot of
> computation.

I wonder if the techniques to generate the MD5 hash collisions[1] could
also be used to cut down the search space for finding an inversion.

In any case, average people don't pick passwords that take much
search-space to find. Having a 128-bit search-space for the hash
doesn't buy you much if probability-density-function for the chosen
password strings is highly non-linear. If one only has to test the
10,000 or 100,000 most likely passwords to break 15% of the users
passwords having a fancy hash representation in the shadow file isn't
going to buy one much. The weak link is still the user's password.

I'm beginning to think the only way to really protect systems is to
have a $20 usb flash card that is given to each user. The flash card
would contain a 1k-bit key (say ssh's rsa or dsa). The user's
password is ONLY used to decrypt the 1k-bit key. Even if the user
chooses a losing password that is in every cracker's dictionary, it
won't help an external attacker any. The external attacker needs to
search the 1k-bit long space unless they happen to be able to be able
to steal the usb flash card. If they steal the usb card, then and
only then, will they be able to throw the much smaller cracker
dictionary against the users 1k-bit key and try to decrypt it.

-wolfgang

[1] eprint.iacr.org/2004/199.pdf - Collisions for Hash Functions MD4,
MD5, HAVAL-128 and RIPEMD, Xiaoyun Wang, Dengguo Feng, Xuejia
Lai, Hongbo Yu
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
When you talk to musicians about pirates they think
you are talking about the RIAA.

Michael Heiming wrote:

> In comp.os.linux.security Jon Gomez <jon.gomez.04@cnu.edu>:
>> Frank wrote:
>
>>> Hi,
>>>
>>> i'd like to see if it's possible to decode this file....
>>> Could someone help me with this ;)
>>> It'd be nice if you posted the decoded version ;)
>
> Why? If you can read /etc/shadow you are already root and have no
> need.
>
> [..]
>
>>> root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::
>
>> man 5 shadow
>> man 3 crypt (or libc infopage)
>
> Looks to me like MD5 password hash, not crypt(), more or less
> zero chances reverting it back to the password.


Yes, yes. But the libc info doc edition 0.10, it discusses using crypt()
for md5. So you mean, it's not DES.

Jon.

--
-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

Wolfgang S. Rupprecht wrote:
> I'm beginning to think the only way to really protect systems is to
> have a $20 usb flash card that is given to each user. The flash card
> would contain a 1k-bit key (say ssh's rsa or dsa). The user's
> password is ONLY used to decrypt the 1k-bit key. Even if the user
> chooses a losing password that is in every cracker's dictionary, it
> won't help an external attacker any. The external attacker needs to
> search the 1k-bit long space unless they happen to be able to be able
> to steal the usb flash card. If they steal the usb card, then and
> only then, will they be able to throw the much smaller cracker
> dictionary against the users 1k-bit key and try to decrypt it.

Meaning a smart card?

Perhaps we should make passwd generate the password for the users :P (Or no
setuid, and hand it out...) But I was so wowed when the admin here at my
school set an empty password for root. I guess that's the advantage of
having a spare test computer.


> [1] eprint.iacr.org/2004/199.pdf - Collisions for Hash Functions MD4,
> MD5, HAVAL-128 and RIPEMD, Xiaoyun Wang, Dengguo Feng, Xuejia
> Lai, Hongbo Yu

Click-y. Thanks so much for posting this. I was wondering very much.

Jon.

-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

> In article <cp6ki9$je4$05$1@news.t-online.com>, Frank <lol@privacy.net> wrote:
> :i'd like to see if it's possible to decode this file....
>
> :root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::

> Thus, in order to decode the password, one would have to find a
> password whose MD5 was represented in base64 as xEeZmr2fGEnKjVAxzj/o51 .

password when hashed with BZftq3sP as a salt matches
xEeZmr2fGEnKjVAxzj/o51

> There are services which are generating pretty much all 8 bit
> lowercase + digit plaintexts and using MD5 to encrypt them and
> saving the result, but these services don't work with the "salted"
> MD5 of shadow password files.
>

--
Justin Murdock

Having nothing better to do that spam and xpost in alt.hacking,
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote :

>In article <cp6ki9$je4$05$1@news.t-online.com>, Frank <lol@privacy.net> wrote:
>:i'd like to see if it's possible to decode this file....
>
>:root:$1$BZftq3sP$xEeZmr2fGEnKjVAxzj/o51:12747:0:99999:7:::
>
>That looks like a standard /etc/shadow line in an OS that allows
>the glibc extensions to encrypted passwords. According to
>
>http://unixhelp.ed.ac.uk/CGI/man-cgi?crypt+3
>
> GNU EXTENSION
>
> The glibc2 version of this function has the following additional fea-
> tures. If salt is a character string starting with the three charac-
> ters "$1$" followed by at most eight characters, and optionally termi-
> nated by "$", then instead of using the DES machine, the glibc crypt
> function uses an MD5-based algorithm, and outputs up to 34 bytes,
> namely "$1$<string>$", where "<string>" stands for the up to 8 charac-
> ters following "$1$" in the salt, followed by 22 bytes chosen from the
> set [a-zA-Z0-9./]. The entire key is significant here (instead of only
> the first 8 bytes).
>
>
>Thus, in order to decode the password, one would have to find a
>password whose MD5 was represented in base64 as xEeZmr2fGEnKjVAxzj/o51 .
>
>MD5 is a 128 bit hash, so brute force would require an
>average of 2^127 operations to find a match. That's a lot of
>computation.
>
>There are services which are generating pretty much all 8 bit
>lowercase + digit plaintexts and using MD5 to encrypt them and
>saving the result, but these services don't work with the "salted"
>MD5 of shadow password files.
>
>http://passcracking.com/


What was wrong with leaving that in its original froups
(there were only two at that point), spamming twat.


--
/------------------------------------------------------------\
| It's too bad that stupidity isn't painful |
| --Anton Szandor LaVey |
\------------------------------------------------------------/

In article <v65rr0dkc9g0vpopi0u5ere0dq2h120ik5@4ax.com>,
Lensman <op09_Black@bechtel.com> wrote:
:Having nothing better to do that spam and xpost in alt.hacking,
:roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote :
:[...]

:What was wrong with leaving that in its original froups
:(there were only two at that point), spamming twat.

The headers of the message I replied to had:

Newsgroups: alt.hacker,alt.hacking,be.comp.security,comp.os.li nux.security,comp.security.misc,comp.security.unix
Subject: shadow file
Followup-To: alt.hacker

Did the copy of the OP you received have something different?


Also, for my edification, could you point me to an RFC or
well-known publication that I could employ to re-examine my message
in order to determine the manner in which it was "spam" ?
Did they perhaps redefine the BI calculation, or did they lower
the BI limit so that EMP now includes BI's as low as
squareroot(6) ?
--
Inevitably, someone will flame me about this .signature.