[phire]

But we don't need to reverse the one way hash. The goal is simply to find the original password and brute forcing is good enough.

The brute forcing algorithm doesn't care that you only have a partial hash. All that does is increase the chances of collisions. (Side note, rainbow tables might care, I'm not sure how suitable they are for wildcard hash matches)

For example, I burned 8 guesses and I got enough greens to give me 108 bits of the hash. You can scrape out a bit more entropy by processing the yellows and greys, but 108 bits is more than enough to identify the password with very little chance of collisions (the chance of collisions hits only hits 50% once you get to 17 character alphanumeric+symbol passwords).

You can then use the two remaining guesses to resolve any collisions and lock in the correct answer.

[chrismorgan]

The goal is to find the original password, but you’re finding the hash. Finding the hash doesn’t help you in the slightest with finding a password that hashes to that.

Put another way: here, I’ll tell you the hash: DF50B84AFEE438987ECE1542A4D1BCAB4079215EF38C3C3CBB2F4A122886DF27. Now tell me the password. You have 0% chance of succeeding in your lifetime, to at least a dozen decimal places.

[phire]

It all depends on how complex the password is.

For an 8 char password, it would take a few min.

For a 10 char alphanumeric password, several months on a single GPU

For a 12 char alphanumeric password, Half a century on a single GPU, less if you are willing to throw money at it.

The time would be significantly reduced if the password was vulnerable to a dictionary attack