Ah, you are technically incorrect in saying there are an infinite number of "nicetry"+i hashes. There are an infinite number of "nicetry"+i passwords, but eventually there will be collisions as the hash set stays a constant size and the password set grows without bound. "Infinite" isn't a term to throw around too lightly.

There are 2^128 possible MD5 hashes. When it becomes impossible to increment a counter to a number, that's as good as infinite.

The point is that it's unnecessary to find the plaintext; all you need is some plaintext that produces the same hash value. It doesn't matter if your actual password is "zipobibrok5x10^8" when "fordprefect" also gets you into the system. (That, of course, only applies to a single system -- or to a cluster of systems all using something like an unsalted MD5. It would matter if you're trying to leverage a password found on a cat fanciers' site to empty someone's bank account.)

I actually think you're missing the point here. While it is true that an infinite number of strings correspond with each md5 hash, the question was about trying to actually find a match. With a suitably large hash, say 256 bits, it becomes physically impossible to even count that high, let alone compute that many test hashes. A problem that is too large to evaluate is effectively infinite.

(Yes, md5 is 128 bits and might be possible if an entire country dedicated itself to the effort. Or an attack on its flaws could be used. But both these points are tangential to themouth's use of infinite.)

With the technique under discussion (using Google to search for the MD5 hash), it doesn't really matter what the computational cost of finding a plaintext for the every possible hash value is -- you're not brute forcing a collision, you're doing a search using someone else's enormous resources. That's always going to be O(1) from your point of view (with a lot of overhead, of course).

In my experience, it is accurate. Google doesn't know "nicetry99", but it does know "octopus99", "octopus98", "octopus97", "hacker99", "hacker98", "hacker97" etc.

Anecdotal evidence might as well be no evidence. I'm not saying that you don't have a unique or clever idea, but it should be judged on its merits. This tool will be great for finding common passwords and variants where a system uses unsalted MD5 hashes; but it relies on known hashes, so for the vast majority of possible input strings that have no reason to be generated or indexed by Google it's ineffective.

Anecdotal evidence is perfectly fine to say 'usually' here.