Given the hashes, it's actually fairly straightforward to brute force something that will work most accounts, as people seldom use more than 10 characters in a password, especially on a web service.
Are you absolutely certain that some clever Ph.D. hasn't come up with a method of breaking a hash code?
I don't think you really understand what a hash is. A hash is not an encrypted password. It is the result of a defined algorithm executed on the password.
Here's a really good example of a hash (this particular example is using the MD5 hashing algorithm: 265043fa6b45db9f70c260e87d1a592c
There is no way you could take that hash and use it to reconstruct the document it represents. How do I know? There simply is not enough information there. That was the MD5 hash of an ascii text file of the King James Bible. There is no way to extract 5 MB of data from those few characters.
Let's look at this from another direction as well.
Here's a little one line shell script for generating some hashes:
for x in abcde qwerty 1234567 gjhagjadklgjhalgkafjghadflgkd 5 ; do echo $x | md5sum;done
Here's the output of that script: 9b9af6945c95f1aa302a61acf75c9bd6 - a86850deb2742ec3cb41518e26aa2d89 - 1b504d3328e16fdf281d1fb9516dd90b - 9dd78b66da1c2e5e38ad521594b6c5b4 - 1dcca23355272056f04fe8bf20edfce0 -
Now, you may well be able to run a password guessing program that could come up with the passwords abcde, querty, 1234567, and 5, but you'll spend a lot more time trying to crack the account whose password is gjhagjadklgjhalgkafjghadflgkd. You'll notice that the hash doesn't vary in length regardless of how much data is fed to it. The has of just the number "5" pretty mch looks like the hash for gjhagjadklgjhalgkafjghadflgkd, so you can't determine from the hash how long the password is. Rather, you simply brute force all possible passwords until you hit one that has the same hash as the one you're looking for.
You'll notice I didn't say that you''ll necessarily hit the same password, but you will have found some string that hashes to the same value, so for your purposes, it works just as well. This is because it is possible to have what they call a 'collision'. A hash collision is where two different texts result in the same hash. They aren't likely, (in fact they are pretty darned rare, especially when you're dealing with strictly ascii text), but they are possible. You are probably more likely to hit multiple lotteries than hit such a collision by chance, but you do know, don't you, that there is a fellow who has actually won 2 lotteries?
Anyway this is all a long-winded explanation of why you don't actually reconstruct data from a hash.
However, it is still a very, very bad thing for a company to provide these hashes to our feral government, because of how much easier it makes it for the feral thugs to crack people's accounts given how poorly most people construct passwords.
Do you have any idea how few tears I would shed if I woke up tomorrow morning and learned right here on FreeRepublic that a meteorite had struck the White House lawn, and had created a crater about 10 miles in diameter the previous evening?
Given that hash codes inherently allow multiple inputs to generate the same output, this is a far less demanding problem.
Not simple, not trivial, not straightforward, but in the realm of possibility.
Especially if you know the algorithm used to generate a given provider's hash.