0

I happen to have a few hashes generated with code that did this (it has been changed to use a more "standard" bcrypt call):

$ python3
>>> import hmac
>>> hmac.new(b'The quick brown', b'123456', digestmod='sha1').hexdigest()
'c3b8986510970b778b26c42d954a93411f32f301'

i.e., it calculates hmac.sha1(key=salt, message=password) while john, by default calculates hmac.sha1(key=password,message=salt)

Is there a way to convince john the ripper to brute force hmac.sha1(key=salt, message=password)?

mathieu
  • 125
  • 5
  • Why is this a problem? It's the same format. You just swapped the key and the message. What's the output of john when you try to crack the hash? You don't include anything we would need to help you troubleshoot. – schroeder Sep 15 '20 at 14:34
  • Why is your password method swapping the key and message? – schroeder Sep 15 '20 at 14:51
  • Why is the code written that way ? I do not know. This is how it is. – mathieu Sep 16 '20 at 08:48
  • Right ... well, if your code, which you can't change, reverses the key and the message, then `john` is not your tool. John brute forces the key. – schroeder Sep 16 '20 at 08:53
  • Thanks schroeder, I updated the question to clarify it. Regarding the code, I already changed it (to use bcrypt) but I wanted to check the old passwords generated before I made the switch so, I cannot go back in time :/ – mathieu Sep 16 '20 at 09:03
  • FYI, that code happens to be not mine. I guess it was written that way precisely to make it harder to run a tool like john on the hashes. For future reference in case anyone cares: https://github.com/GoogleCloudPlatform/webapp2/blob/deb34447ef8927c940bed2d80c7eec75f9f01be8/webapp2_extras/security.py#L200 – mathieu Sep 16 '20 at 09:08
  • Hashcat could do it, I think.. – Henno Brandsma Dec 20 '20 at 22:48

0 Answers0