Re: reversing hash ?

From: Vedat Hallac (mvhallac_at_crosswinds.net)
Date: 05/15/03 

Date: Thu, 15 May 2003 18:22:16 +1000

On Thu, 15 May 2003 00:04:27 +0200, Spamhater wrote:

> Ok.... wow... I think I understood 70% of what you are saying :-) But that's
> due to my math knowledge :-(
>
> I looked through the script again, is this correct ?
>
> There are several passwords that give the same hash of 894203311 but there
> will only be a few (or one ?) that when hashed with multiplier 9 give the
> exact result which is needed to decode the URL ?

That is correct. Trying to brute force the password is only going to end
up coming up with possible passwords, and believe you me, there are a lot
of them to get by brute forcing the password. You are better of generating
all valid passwords and trying to figure out the correct one.

I have found one web site out there that uses a very similar script to
protect its data. The fools. I have tried a value generated by the method
I described as the password, and it accepted it as a correct password, but
failed to locate the URL (as expected). But I didn't want to spend/waste
any more time on this; so their passwords are safe from me. :-)

One other way to attack the problem is to forget about the passwords, and
decode (or try to decode) the URL directly; then figure out the password
if you really want/need to. You shouldn't, because by then you'd know the
URL anyway. You could try each possible combination with their server, but
it would be suspicious if you showed in their logs trying a million URLs.
See below to see how you can forget about the password.

I had a look at the rest of the code. What they do is to subtract each
digit of the second hash from the "encrypted" (I really don't want to use
that word, let's say encoded) URLs. Even better is that the same digit is
subtracted from all words encoded. In your example, you had two URLs for
the user. Therefore, the first character of both are changed by the same
amount. Even better (for you) is the fact that the amount of change is 10
characters. So, for each character of the URL, you have a set of 10
possible letters. Sweet. For example, the first URL is 6 letters long, so
you have a search space of 10^6 to locate the correct one. Moreover, they
keep the symbols as it is, so the '.' in the second name will stay the
same. The final three letters would be the extension of the file name.
Since it is going to be displayed by your browser, it would be either
'txt' or 'htm'. So you can get the last three digits of the second password
trivially. This may still end up with more than one possible password, but
would reduce the search space considerably.

As I have stated before, this scheme is very easy to break.