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:::

In article <cp6ki9$je4$05$1 [at] news.t-online.com>, Frank <lol [at] 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.

roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

> In article <cp6ki9$je4$05$1 [at] news.t-online.com>, Frank <lol [at] 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 [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote :

>In article <cp6ki9$je4$05$1 [at] news.t-online.com>, Frank <lol [at] 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 [at] 4ax.com>,
Lensman <op09_Black [at] bechtel.com> wrote:
:Having nothing better to do that spam and xpost in alt.hacking,
:roberson [at] 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.linux.securi ty,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.

Having nothing better to do that lurk in alt.hacking,
roberson [at] ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote :

>In article <v65rr0dkc9g0vpopi0u5ere0dq2h120ik5 [at] 4ax.com>,
>Lensman <op09_Black [at] bechtel.com> wrote:
>:Having nothing better to do that spam and xpost in alt.hacking,
>:roberson [at] 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.linux.securi ty,comp.security.misc,comp.security.unix
> Subject: shadow file
> Followup-To: alt.hacker
>
>Did the copy of the OP you received have something different?

Yes.

Looking at it though, it appears my newsreader has chained you onto a
different message in the same thread. Under normal circumstances,
that would cause me to issue a sincere apology, but...

>
>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) ?

.... you are such a tedious wannabe-patronising bastard that
I'm not going to bother.

Oh well.

HAND


--
/----------------------------------------------------------- -\
| Machines take me by surprise with great frequency. |
| Alan Turing |
\----------------------------------------------------------- -/