6 ms·

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 wit

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!

nwh 12y ago
I'm very much aware of that. I'm saying that because they're disallowing the submission of spaces, they aren't hashing their passwords when they get to the server. > they're checking the string server-side, before hashing and storing the hash to their persistent data store. But why? People don't just add a rule because they feel like it, I'm suggesting that they are storing it in a stupid way that is not hashed and does not allow spaces. > 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. The output of a cryptographic hash is completely random, you can't do any sort of analysis except for determining H(a) == H(b). You don't even know if H(b) was the same input as H(a) or just a collision against it.
- arcticPeril 12y ago
  > But why? 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.
  - nwh 12y ago
    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 12y ago
      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 12y ago
        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.

nwh 12y ago

I'm very much aware of that. I'm saying that because they're disallowing the submission of spaces, they aren't hashing their passwords when they get to the server. > they're checking the string server-side, before hashing and storing the hash to their persistent data store. But why? People don't just add a rule because they feel like it, I'm suggesting that they are storing it in a stupid way that is not hashed and does not allow spaces. > 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. The output of a cryptographic hash is completely random, you can't do any sort of analysis except for determining H(a) == H(b). You don't even know if H(b) was the same input as H(a) or just a collision against it.

arcticPeril 12y ago
> But why? 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.
- nwh 12y ago
  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 12y ago
    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 12y ago
      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.