[nwh]

You've utterly missed the point of this.

If they hashed the user input, it wouldn't matter what the client gave them in terms of password requirements. Spaces, special characters, arbitrary lengths up to tens of thousands of characters would all be fine with a cryptographic hash, there's no way the resulting hash would be anything but a fixed length of n bytes. Nothing "evil" can make it through being hashed.

The password requirements Flickr has set show that they are not using a cryptographic hash, the limitations on length and character set imply that they are being stored incorrectly, either in plain text or a space delimited format. There's no reason to have these limitations if this were not the case.

[arcticPeril]

So you're just going to implicitly trust the user's browser to generate the hash for you? Good luck with that, sir.

And there is a reason to limit length, the very obvious reason being that short passwords are easier to brute force.

Reduced character sets (numeric only, for example) are also easier to brute force, so by forbidding spaces, technically, they've reduced the character set of their passwords by at least one character (not that it's of any particular concern, all things considered).

By the way, I made mention that perhaps they're encrypting the string, and not hashing it. Did you miss that part?

[nwh]

What the hell? When did I suggest that? Client side validation wasn't even a part of this, the rules are clearly enforced at the server as well.

> 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.

[arcticPeril]

So, encryption (as opposed to hashing) COULD be prone to frequency analysis (depending on the cipher used, ROT13 for example, ha ha!). IF that's what Yahoo! were using to protect their password data. But that's a big "if."

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?

I think I may have misinterpretted the following:

  > If they hashed the user input, it wouldn't matter 
    what the client gave them in terms of password 
    requirements.

To me, I read that as "If they (being the client) hashed the user input, it wouldn't matter what the client gave..." my mistake.

[gaadd33]

I don't see how setting business rules means that they aren't using a cryptographic hash. Can you explain why that has to be true?

Perhaps eliminating a frequently made mistake by people who don't have much computer expertise is the reason. Wouldn't it be possible that they have found that a large number of support requests for newly created accounts are due to people accidentally adding spaces? So by eliminating spaces, they can still hash the contents without a problem however they also reduce the support load and increase the usability by a subset of their users.