> By the way, I made mention that perhaps they're encrypting the string, and not hashing it.
Encryption is the same, it's content agnostic. 20 characters doesn't make any sense with the size of a block cipher.
But, as you mentioned, hash funtions always produce a fixed-length string as their output, so, hypothetically, if an evil-doer comprised the whole Yahoo! password database, and saw randomized byte values of varying length stored for the password data, it would be obvious that the passwords were encrypted, and not hashed. In which case, you'd be right: they weren't hashed, they were encrypted.
But still, I don't think forbidding spaces necessarily precludes the use of hashes. I also don't think Yahoo! is using a space-delimited data format for storing password data. Or at least if they were, I'd be as shocked at that as I would be to find out that they protected passwords with ROT13 or triple DES (encrypting a password with AES might be conscionable though).
To answer your question:
> When did I suggest that?
> If they hashed the user input, it wouldn't matter
what the client gave them in terms of password
requirements.