Assuming a service doesn't store a plain text password, am I right in saying that the answer to this question depends on the service? On a bad service, the hash length is related to the password length. On a good service, they're unrelated. That's my guess.
Also, to what extent does doubling a password increase security? So instead of using password, how about using passwordpassword?
Please note, I'm not an expert, so a user-friendly explanation would be welcome.
If the length of the hash varies depending on input, then it is not a hash. A cryptographic hash function, by definition, offers a fixed-size output, regardless of the input. For instance, SHA-256 offers a 256-bit output, always; never more and never less.
Password hashing is a specific activity which is often discussed in this site. The short answer is: use bcrypt. It handles the fine details properly -- and there are many.
As for "doubling" the password, it adds security only insofar as you may elect to do it or not to do it, thus doubling the size of the space of possible passwords. If you do it systematically, then no, it does not increase security. Also, password length may leak (when you type a password, your office colleagues may easily hear the number of keystrokes, for instance).
The strength of passwords does not come from length or special characters or other traditional rules; a password is exactly as strong as it could have been different. The number of possible values for a password (given your method for generating the password) is the key parameter. Anything "witty" here is a bad idea: remember that we must assume the attacker to be always as smart as you. So don't try to make passwords with an idea of "the attacker will never think of that !": the attacker already thought of it, before you.
A good password is generated randomly, with dice, coin flipping, your cat chasing a toy mouse over a plank which has been divided into numbered areas, or even, should it come to that, with a computer running a random number generator.
In a perfect world, Thomas Pornin is completely correct. The fixed output length should completely obfuscate the contents, to include the length of that content.
There are, however, examples of hashing utilities which expose themselves to different types of cryptanalysis which can reveal information such as content length. The most notable example of this is, of course, the NTLMv1 'hash'. Due to some rift in the temporal vortex of mathematics, if a value is shorter than 8 characters, the NT LanMan v1 hash will pad out the remainder of the input stream and so produce a consistent output value of the second block of the hash. Literally, if you have any passwords that are fewer than 8 characters you would get a consistent second block of '0xAAD3B435B51404EE'. If you're interested in some good ol' 'face palm' reading just web search on LANMAN security. Good times.
So the take away here should be: yes, hashing systems should always provide a unique output for different inputs, and should not ever provide any information about the contents used to generate that hash. As a developer or security researcher, however, you also have a responsibility to research all of your cryptographic/hashing systems/algorithms to ensure that they comply with your security goals.
Cryptographic hash functions offer a fixed-length output, and do not "correlate" with the input (you do not get a "close output" for a "close input"; if only one bit differs in the input, then the output will be all scrambled).
Thus, the only way for the attacker to obtain the password length from the hash is to obtain the actual password itself, exact to the last bit.
If your password has enough entropy (i.e. was chosen at random from a large enough set of possible password values) and the hash function is adequate, then this will require too much effort for the attacker to succeed with non-negligible probability.
(Of course, your co-workers or room mates can simply pay attention when you type your password: it is not that hard to count the keystrokes from the sound they make...)
With any serious hash scheme, the size of the hash will be constant, and more generally the value of the hash does not depend on the password in any detectable way. If the size of the hash depends on the password, then the hashing scheme is completely broken — it's probably not a hash at all but encryption (i.e. something reversible).
Whether doubling your password adds security depends on the attacker. I expect you're thinking of the attacker trying to find the password from the hash (if the attacker grabs your password from a keylogger, it obviously makes no difference). If the attacker is trying passwords in order of increasing length, doubling the password makes it a lot more resistant — but few attackers are that stupid. If the attacker is using a reasonable generic distribution of passwords when trying to reverse the hash, then doubling the password doesn't add much. If the attacker is targeting you and knows that you've doubled the password, then doubling was useless.
There is a way to quantify how much work a password selection scheme causes for an attacker: count how many passwords are possible, with no way for the attacker to know which one you've chosen. This is called the entropy of the password. If you flip a coin to decide whether to double your password or not, then the attacker has no way to know whether you've doubled it, so he has twice as much work (one extra bit of entropy).
Having to type, on average, half as much (50% chances of having to type twice as much) is not a good investment for merely doubling the work of the attacker. If instead you add another random letter at the end of your password, you multiply the attacker's work by 26, which is about 4.7 bits of entropy. If you merely flip a coin to decide whether to add a or b at the end of your password, that adds one bit of entropy, and only one extra character to type.
Also, if the attacker has partial information about your password (for example from observing or listening you type), the length is likely to be part of that information. So doubling brings no security in this scenario; a fixed-length password selection scheme is more robust.
As Thomas has said, a true and proper cryptographic hash function should not leak any information about the password. This is due to a few things:
As has been mentioned in my comments, and included in grawulf's answer, there have historically been examples of hashing functions which violate these principles. Perhaps the most well-known example of this is LANMAN (a.k.a.: LM hash, or LAN Manager hash). This hashing function was used in versions of Windows prior to NT, and is still included (though disabled by default) for backward-compatibility in modern versions.
The problems with LANMAN are many, but most of them are rooted in its use of DES - especially the part that allows for guessing a user's password length. DES is limited to a 56-bit key length, which translates to 7 bytes or ASCII characters. Of course this must have been known, even in pre-NT days, to be too small for a reasonably strong password.
So, Microsoft's work-around was to split the user's password in half, hash each half separately, then stick the hash strings together to form the final LM hash. This would allow users to create passwords up to 14 characters long. For passwords shorter than 14 characters, there would be an added padding of null characters at the end (prior to splitting the password) to fill out the rest of the DES key(s). Of course, this means that all passwords shorter than 7 characters would end up with the latter half of their hash (having started as all null characters, and hashed without salt) being identical to all other passwords shorter than 7 characters.
If Microsoft had used a per-user salt, it would at least have prevented the easy guessing of a user's password length from the hash output. It would also have made dictionary attacks a fair deal more difficult. However, there are other inherent weaknesses (beyond the scope of this question) in the function which still leave it wholly unsuitable for use in today's world.
Modern cryptographic functions are much stronger and smarter than this, and therefore much less likely to leak any particular data about your password's length. However, it is good to bear in mind this historical detail as an example of how not to hash passwords. (Of course, it's never a good idea to roll your own crypto anyway.)
TIP: While hashing passwords with LANMAN has been disabled by default since Vista, it is still an available feature for backwards-compatibility. If you want to make sure that your Windows passwords cannot and therefore will not be processed as LM hashes on any Windows system, despite how the system administrator may configure it, make sure your passwords are at least 15 characters long.
A concept called entropy (or randomness) is the key. A brute force attack simply has to meet the lowest level of entropy involved. Generally speaking, a well hashed password will be of a length that makes it have higher entropy than an average password. It is possible to look for collisions against the hashes, but if the password you use has less entropy than the hash itself, then it is easier to just try and guess the password.
For example, if my password 123 is hashed to a3afj93a93ufa9f9uafnmac, it would take far fewer guesses of things to try the hash for than if my password had similar or greater entropy (or randomness). An attack called a rainbow table can be used against a large number of hashes at the same time if they are not properly secured by computing hashes for low entropy passwords and looking for matches. The concept of a salt increases the entropy of the password prior to hashing by appending a random value to the beginning of the password. This makes it so that each password has to be individually attacked even if the attacker has access to the hash tables.
A simple example. My hashing algorithm works as follows. Given a number N, hash of that number is defined as
HASH(N)=N%100.
If i given 123 as input hash will be 23 that is 123%100. If i given 2365736 as input hash will be 36. If the input is 123867823 hash will be 23. Now the question for you. If given 23 as hash value can you tell its input value? you can't tell a perfect value.
Hashing function is not exactly similar to this, because this will generate duplicate values that is 23 as hash for both 123 and 175623. Like this a hash function is not reversible.
