0
$\begingroup$

I have the following conditions:

String which consist of "STRING+key+ID+key" is hashed with md5. I have a knowledge of STRING (10 chars), ID is probabilistic (int 15), key is 15 chars long (a-z A-Z 0-9) and it's same on both occurrences. I can produce multiple hashes but without knowledge of key.

I guess collision is not going to work in this case as STRING is appended at the beginning and ID between keys. Is there actually any other option then brute force.

Produced hash is used as some kind of integrity check so you cannot alter the parameters. Key is hardcoded on the both sides (frontend and backend)

POST: {"STRING":"ASDFGHJKLM","ID":"123456789012345","hash":"md5hash"}

$\endgroup$
  • $\begingroup$ You probably now the rainbow tables for MD5. Is this an authentication stuff? I'm asking because the more information the better you get. $\endgroup$ – kelalaka Oct 8 '18 at 18:30
  • $\begingroup$ I've been looking at rainbow tables but I have found them only for up to 20 chars. This string is 55 chars long. String and ID are included in post, hash is "signature" so you cannot alter the string and ID parameters. Some kind of authorization... $\endgroup$ – Branko Oct 8 '18 at 18:51
  • $\begingroup$ Rainbow tables are not exactly intended to find the preimage, so size is not really important. They work only if there is no salt in the hash. There are MD5 collusion generators, bishopfox.com/resources/tools/other-free-tools/… . What I see, if you cannot find the preiamge, then collusion is not going to work. As a result, you have to brute force. $\endgroup$ – kelalaka Oct 8 '18 at 18:58
  • $\begingroup$ Thank you for your answers. I have edited the question to add more informations. My guess is that collusion is not going to work as string has to in exact format, it is reproduced on the backend side to check if parameters were altered. I will take a look at collision generators anyway. I am wondering what would be cost of bruteforcing 15chars. $\endgroup$ – Branko Oct 8 '18 at 19:13
  • $\begingroup$ look at hashcat $\endgroup$ – kelalaka Oct 8 '18 at 19:13
0
$\begingroup$

Passwords, $p$, when only secured with a hash function $H$ on the database as $H(p)$ for login systems, is vulnerable to finding pre-image or secondary pre-image attacks.

Secondary pre-image : given $ H(p)$ find $p' \neq p$ s.t $H(p)=H(p')$.

The famous rainbow tables are generated to more effectively find the pre-image or secondary pre-images. To countermeasure the rainbow tables, salt is one of the solutions.

As I can see from your problem there is a salt and these prevent the rainbow attacks.

  • As a result, you cannot benefit from the salts.

The only choice is the brute force.

And as you noted;

  • AWS p3.x16 has the power of 450GH/s.
|improve this answer|||||
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.