My mistake was that I thought he was sending hash(password + challenge). If that were the case, one could do rainbow table attacks on the unsalted password.VladSun wrote: It still suffers from the "empty challenge string" issue.
...
I.e. the MITM gets the SH256 of "hashedpassword:lowercaseusername:" - still offline "dehashing" attack is possible. There is no time window limit for doing this.
And when the MITM has successfully "dehashed" the "hashedpassword:lowercaseusername:" he can respond with a correct challenge-response string to any server sent challenge string.
With the current setup the empty challenge leads to:
hash(username + hash(password)), which is still a "personally salted" password which cannot be attacked with precomputational methods, it will have to be bruteforced.
Continuing this line of though, since Mallory sits in the middle and has the challenge value (even if he cannot control it, i.e. a read-only MITM scenario) he has:
hash(username + hash(password) + challenge)
Since he knows the username and challenge, the task is essentially the same as before - bruteforcing a "personally salted" password. Being able to manipulate the challenge doesn't change anything.
So in this case Mallory wouldn't have any advantage over having a write-able MITM attack, that's why I said I was wrong in my original scenario (which was much more severe because of the precomputated attack possibility)