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.
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?
Because you cannot trust any checks performed on the client-side, since the user may have total control over the client-side system, and possess the ability to (somehow) bypass or spoof client-side validation.
Client-side validation only exists to pluck the low-hanging fruit, and provide convenience to the majority of users. You cannot rely on any client-side events, when attempting to secure server-side resources.
All user input must be considered evil until proven otherwise.
Actually, they are (or could be, given that I don't know for sure because I don't work there).
It merely means that they are most likely looking for spaces with client-side JavaScript, and rejecting any string that contains spaces.
Or, they're checking the string server-side, before hashing and storing the hash to their persistent data store.
Either way, as long as the connection is secure, it's reasonable to inspect the string in plain-text, both client-side and server-side, before creating the hash, as long as they actually create the hash when they do actually decide to save a representation of the password, rather than saving the plain-text password itself.
Part of me would like to guess that the reason spaces might be forbidden in passwords (and pass phrases) would be to prevent frequency analysis. But that doesn't really make much sense, when it comes to hashes, does it? So then, might the case be that they are storing the passwords with reversible encryption, and decrypting the token for a match? In my mind of minds, I doubt it, but you never know. What I really think is that the password policy is simply contrived and idiotic, and whatever rationale they've used to forbid spaces is silly and ill-conceived.
Either way, I agree with the author, whole-heartedly. That is a damned frustrating sign-up process. Two-factor account creation AND a CAPTCHA check? Holy moly!
Maybe I'm missing an important detail about the lifecycle of arctic ice, but...
If the arctic ice contains plastic particles...
And the particles are man made...
And man has only been making small plastic particles for roughly 100 years...
That would mean that the arctic ice was, at some point in the recent 100 years, ordinary sea water polluted with small plastic particles.
If this ice... was sea water in the recent past, then it must be superficial ice.
If superficial arctic ice is young enough to contain plastics, and is now melting, then this marks the return of sea water from as recent as 50-100 years ago...
If melting polar ice, polluted with plastics, is a new and disturbing event, then...
Does this mean that this is the first time polar ice of that age is melting?
If 50-100-year-old polar ice is only melting just now, for the first time, then, in terms of rising sea levels, does this mean that sea levels have, thus far, only risen to their state as they existed at the end of the 19th century?
Or, is it that the arctic polar ice cap completely melts every summer and refreezes every winter?
If so, then won't a similar amount of plastic be recaptured when the arctic polar ice cap refreezes? Or are we now fretting at the idea that the arctic polar ice cap will fail to refreeze?
And doesn't that mean that 2 years ago, and 10 years ago, the polar ice cap was capturing just as many plastic particles when it refroze?
And if this plastic-bound ice has also melted during the past few summers, didn't it redistibute its captured plastics back into the ocean?
If the arctic ice cap is (or was) trapping large quantities of man-made plastics, then the sea ice doesn't seem to be the real story here.
The real story seems to be the horrendous amount of plastics in the ocean. The arctic polar ice cap, on the other, hand seems to be an unfortunate additional detail.
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:
I think I may have misinterpretted the following:
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.