You seem to misunderstand how passwords work. Every server hashes your password, that is why your password has to be cracked in the first place. If it was stored in plaintext, they could just extract the password from the server. Instead, they have to try and crack your pass be hashing candidate passwords until they find one with a matching hash. Thus, entropy doesn't change at all.
If you are talking about hashing a password, and then using the hash as your password, seems like a really bad idea. Hashing mechanisms are not designed to be applied more than once, and while there would probably be no issue, there is still the chance that repeatably hashing a pass leads to a vulnerability in the hashing mechanism. It is better to just let the server hash your pass (like they already do).
Yes, but a hashing algorithim creates a string of numbers specific to that word, while having extreme entropy. Each letter/number generated is pseudo-random, hence confusing crackers. Yes, it is easier to crack a stolen hash, but that's not what the average user should worry about. Servers encrypt passwords in SHA1. New ones, at least. If it still uses MD5, shame on them. I was suggesting hashing in SHA512, having 128 characters and being uncrackable.
Hashing does not magically create huge amounts of extra entropy. If a cracker is just trying straightforward alphanumeric brute force, then yes using the hash instead does make it more difficult. But if hashes are used as passwords by enough people, crackers will just, in addition to trying every possible password, try the hash of every possible password. The number of possibilities for the hash is not the total number of possible hashes, but the total number of possibilities for the password that gets hashed.
A better idea is to use a password manager (I use KeePassX). That way you can use different random passwords that are as long as you like for every website, and you only have to remember one password (though it should be a strong one, since it protects all your other passwords).
> pseudo-random, hence confusing crackers
No, hashes are the opposite of random.
Yes, we all know how a hashing algorithm works.
No, that is not how cracking works.
Entropy is based solely on character set and length (and sometimes words if the attacker is using a dictionary attack. (a password of “password” has no entropy, for example)). Taking into account that a hash is outputted in hex, so there is only 15 characters possible, and that most sites don't allow passwords greater than around 17-20 characters, and a hash makes a very weak password in comparison to something that uses the full character set to crack.
The randomness of your password has literally no effect on how easy it is to crack unless you are up against a rainbow table based attack or a dictionary attack.
> Servers encrypt passwords in SHA1
Care to back this up? I would be willing to bet that most sites use SHA-2, if not SHA-3, and that most would spring for the largest variants of those, considering how easy it is to setup, and how big the impact it has on security is. In fact, I am almost willing to bet that somewhere along the line SHA-2 became the standard in some sort of security lib for storing passwords in a DB (MySQL supports it), so it might even be on by default. I know it is for linux (at least the distro I use).
> extreme entropy
I would argue, as I did two paragraphs ago, that this decreases entropy. By a lot, actually.
> If it still uses MD5, shame on them.
MD5 is not all that bad, actually. Really the only reason it is bad for password hashing is that it is fast to generate, generates a shorter hash, and, importantly, people have managed to successfully create hash conflict on purpose with two pieces of valid data. That last point is the important part, and really, even then, with how hard that is to do, and its extreme unlikelihood, its still not that huge a threat.
It's not ideal, but it is not the end of the world either. It's not like it has been reversed