No, but yes, but you're asking the wrong question.
A hash function, formally speaking, is a function from some input set to a finite set. There is no general requirement that the input set have a particular size or form. The input is not necessarily the set of all bit-strings. It's very common to define hash functions on structured data, for example. However, in practice, the reason to use a hash function is to map a “large” set of potential inputs to a ”small“ set of hash values. The point of hash functions is to produce a value with a stringent size limit from a value that doesn't have this size limit. As a consequence, stating that a hash function “can be used to map data of arbitrary size to fixed-size values” is an adequate one-line summary.
Note that “hash function” on its own is not a cryptographic concept. There is a separate concept of cryptographic hash function. In contexts where cryptography is implicit, “hash function” means “cryptographic hash function”, but in a general context such as a generalist encyclopedia article, “hash function” has nothing to do with cryptography.
A cryptographic hash function is a kind of hash function that has some additional security-related properties. Like in the general case, the input doesn't have to be the set of all bit-strings. Unlike the general case, though, it's rather uncommon to consider hash functions on structured input. Usually, when we need to use a cryptographic hash on structured data, we start by encoding the data unambiguously as a bit-string. However, when the data has internal equivalences (for example if it's a sequence in which some elements can be reordered), the representation of the data can be a nontrivial issue and so sometimes it's necessary to analyze the security of the whole mapping from structured data to hash value, and not just the security of the mapping from an encoding of the data as a bit-string to a hash value.
In practice, most cryptographic hash functions take a bit-string as input, and accept input that is theoretically bounded, but practically unbounded. All common cryptographic hash functions accept at least two exabytes of input ($2^{64}$ bits). If a practical requirement for larger inputs was foreseen, the world would adopt new functions that accept longer inputs. So while it isn't mathematically correct that typical cryptographic hash functions accept inputs of any length, it's practically true in the sense that you won't be able to actually run the function on a counterexample.
But the most important part of the answer to your question is something you didn't ask.
A password hash function is not a hash function!
Beware of terminology, it's sometimes misleading. A password hash function shares some properties of a cryptographic hash function, and that's why it's called that way. However there are differences, both in terms of the interface and in terms of the security property. A password hash function does not fit the definition of “hash function” (cryptographic or not), and it shares some security properties with cryptographic hash functions but there are also crucial differences.
A cryptographic hash function is a function $F$ that takes one input (“message”, usually a bit-string) and returns one output (the hash value, usually a bit-string of a fixed size). It must have three security properties (which I'll express here in layman terms — some of the formal definitions are pretty tricky):
- Preimage resistance (sometimes called first preimage resistance): given a “random” $h$, it's difficult to find $m$ such that $F(m) = h$.
- Second preimage resistance: given $m_1$, it's difficult to find $m_2$ such that $F(m_1) = F(m_2)$.
- Collision resistance: it's difficult to find $m_1 \ne m_2$ such that $F(m_1) = F(m_2)$.
A password hash function (for which there's no Wikipedia article that I can recommend, the closest being key stretching) is a function $G$ with two inputs: a password and a salt. Note that unlike a hash function, there are two inputs. The password has a similar role to the input of a hash function, but the salt is new. Like a hash function, a password hash function has an output which is generally a bit-string of a fixed size; however the very closely related concept of key stretching function can have variable-size output.
Given a password as input, to use a password hashing function, you need to provide a salt. There are two ways to do that: you can generate it, or you can read back a stored value (which is normally stored together with the expected output value).
The security properties of a password hash function $G$ have more differences than similarities with the security properties of a cryptographic hash function.
- Password preimage resistance: given $s$ and $h$, it is difficult to find $p$ such that $G(p, s) = h$, even if $h$ is deliberately chosen such that $p$ exists, as long as $p$ is not revealed.
- Input sensitivity: if $p_1 \ne p_2$ then knowing $G(p_1, s)$ does not give any information about $G(p_2, s)$. Likewise, if $s_1 \ne s_2$, then knowing $G(p, s_1)$ does not give any information about $G(p, s_2)$. In other words, the function erases any relationship between the inputs, since any two inputs map to unrelated outputs as long as the inputs are not identical.
- Slowness: the fastest known method for calculating values of $G$ must be as slow as possible.
(Note that whereas cryptographic hash functions are a long-established concept and have a standard presentation and standard terminology, this is not the case for a password hash function. The names I give above are my own, and you're likely to find different presentations of the concept that might break the properties down differently.)
The preimage resistance property for passwords is kind of intermediate between first preimage resistance and second preimage resistance for ordinary (cryptographic) hashes. First preimage resistance would not be sufficient for passwords. First preimage resistance allows certain values of $h$ to be “easy”, because you can always enumerate $h(\mathtt{"a"}), h(\mathtt{"b"}), h(\mathtt{"c"}), \ldots$ and that gives you some hash values with known preimages. This is why finding a preimage is only difficult if $h$ is not deliberately chosen to make it easy. Another way to state preimage resistance is that inverting the function (calculating preimages) can only be done by guessing the input and verifying it. (Guessing includes knowing in advance.) With ordinary hashing, it's supplemented by second preimage resistance, which in some sense says that enumerating values of $h$ is the only way to break first preimage resistance. With password hashing, second preimage resistance and collision resistance are irrelevant. It doesn't really matter if there are multiple passwords for the same account. What matters is that it's difficult to find any of them. The more passwords there are, the more likely it is easy to find one, so in practice password hashing functions tend not to have collisions, but it isn't an absolute requirement.
Password hashing absolutely require that related inputs map to unrelated outputs. You wouldn't want to be able to tell that a password guess is one character off, for example. This property is mostly true of typical hash functions, but there tend to be corner cases where related inputs do map to related outputs (such as length extension attacks). This is not acceptable with key derivation, including key stretching.
Slowness is a specific property of key stretching and password hashing. As we saw above with first preimage resistance, inverting a hash function is prone to guessing. Guessing is very bad for password lookup because passwords are often chosen to be memorable, and that makes them easy to guess. Password hashing must be intrinsically slow to slow down guessing attempts.
