Earlier quoted context omitted.
You can apply a hashing algorithm to a string that contains spaces. The spaces are very much relevant. In MD5 "String with spaces" yields eab431cd212fb8b5ae223acbcfe58cca "Stringwithspaces" gives 3cd297b2d7e48709d92890f88abdde0a
I meant the hashes themselves wouldn't have spaces, therefore any odd database storage requirement wouldn't matter.
I will never be able to log in to Flickr again
31–40 of 43 posts
Re: I will never be able to log in to Flickr again
#32Earlier quoted context omitted.
There isn't one.
Which begs the question why I was downvoted heavily and posted to @shit_HN_says for making the comment.
Now, to be fair, that's an uncharitable interpretation of the comment you're complaining about. But you helpfully make clear in a later comment that that was what you meant:
> I'm saying that because they're disallowing the submission of spaces, they aren't hashing their passwords when they get to the server.
And that just doesn't follow, and that's probably why your comment is getting downvoted, but not why I downvoted it just now. I don't downvote for content, but only for rudeness, unfunny jokes, and complaining about downvotes.
Re: I will never be able to log in to Flickr again
#33Earlier quoted context omitted.
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 pas…
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 o…
> 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.
Re: I will never be able to log in to Flickr again
#34No spaces in passwords? Obviously not hashing them.
To be fair, any other way would be lead to convoluted rules like "no consecutive spaces", "no leading/trailing spaces" or "spaces don't count towards the password length".
This is exactly why forcing users to use strong passwords is a shit idea in the first places. The rules either become ridiculously complicated or you disallow perfectly good passwords. There's no middle ground.
Re: I will never be able to log in to Flickr again
#35Earlier quoted context omitted.
> 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 r…
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 pas…
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.
Re: I will never be able to log in to Flickr again
#36Earlier quoted context omitted.
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 o…
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.
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.Re: I will never be able to log in to Flickr again
#37Re: I will never be able to log in to Flickr again
#38"I was surprised to find out that Flickr now requires a Yahoo account to log in. I’m not sure when this was implemented..." Yahoo usernames were required in 2007: http://news.bbc.co.uk/2/hi/technology/6316761.stm
Re: I will never be able to log in to Flickr again
#39This feels sensationalist to me. Password requirements, a captcha, and (optional I think) phone verification are common on many sites. I was able to create an account in about 30 seconds. I think if the author wants to, he will be able to log in to Flickr in the future
Re: I will never be able to log in to Flickr again
#40Maybe some day, Yahoo will get their heads out of their asses and restore access to my old photos. I'm not holding my breath.