I will never be able to log in to Flickr again(ngzhian.github.io)
ngzhian.github.io
I will never be able to log in to Flickr again
http://ngzhian.github.io/blog/posts/2014-05-24-yahoo-flickr.html
42 comments
This 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
Yes many sites do require that, but Yahoo? I expected a little more from them, does it even make any sense to have such password requirements anymore?
Also, I can't tell for sure if the phone verification is optional, it could be required for new sign ups randomly.
Yea I most definitely can, but I will definitely don't feel like logging in anymore.
The requirements are reasonable in my opinion: the length range prevents too short of passwords, and the variety of characters range prevents some of the weakest passwords: 'password' for example. Not allowing whitespace in passwords can prevent a lot of headaches - say I wrote a password on a piece of paper. How do I represent two spaces vs. one space? Nicer for Yahoo to not have to have to deal with that type of problem from angry users.
All CAPTCHAS are a pain, but the reasons for having one are fair.
The phone verification is a more interesting issue. When I created an account yesterday, it never asked anything about phone verification. And some people don't perhaps have phone access who could be trying to register? If it is randomly mandatory, that's a decent pain and privacy issue. I'm guessing it's probably opt-in or opt-out though
Do I agree with all their decisions? Not really, but I can see why they were made
All CAPTCHAS are a pain, but the reasons for having one are fair.
The phone verification is a more interesting issue. When I created an account yesterday, it never asked anything about phone verification. And some people don't perhaps have phone access who could be trying to register? If it is randomly mandatory, that's a decent pain and privacy issue. I'm guessing it's probably opt-in or opt-out though
Do I agree with all their decisions? Not really, but I can see why they were made
Yep Yahoo! does have pretty much the worst sign-in/sign-up system on the internet. Its even worse than LinkedIn.
Maybe instead of spending billions buying and "sunsetting" random mobile apps or mediocre blog platforms Marissa should dedicate a single high school dropouts salary to fixing the damned thing.
I've all but given up on logging into any Yahoo! property at this point.
Maybe instead of spending billions buying and "sunsetting" random mobile apps or mediocre blog platforms Marissa should dedicate a single high school dropouts salary to fixing the damned thing.
I've all but given up on logging into any Yahoo! property at this point.
At least when you log in to flickr, you don't get the message "Hello- new account signups are temporarily unavailable from this network address space used by your Internet Service Provider", as I've been getting for so long.
Maybe some day, Yahoo will get their heads out of their asses and restore access to my old photos. I'm not holding my breath.
Maybe some day, Yahoo will get their heads out of their asses and restore access to my old photos. I'm not holding my breath.
The worse, I guess, is the password constraint. I really fail to understand why should any application (except banking, may be) force its users to go for difficult passwords. I agree, it weakens the security - but warn them, don't force them. It should be a guideline; not a rule. Whether I want to follow it not is my decision; my risk.
I can't think of a set of rules to make passwords secure. It all feels like smokes and mirrors at this point. Are we going to have a blacklist of passwords that you can't use as passwords anymore (and require users to change password on next log in as we add new items to the blacklist)?
Otherwise, the more I read about these experts who can get 90% of a 16k password hash list figured out in a few hours, I can't think how MyAuntSally1 is any safer than donkey
Otherwise, the more I read about these experts who can get 90% of a 16k password hash list figured out in a few hours, I can't think how MyAuntSally1 is any safer than donkey
My bank insisting on a hard-to-remember 8 character password isn't make it more secure than letting me pick a longer passphrase.
I'm still able to log in to Yahoo! with my Google account, although it seems they're phasing out that option: http://money.cnn.com/2014/03/05/technology/yahoo-google-face...
I found the tool used to generate the blog interesting. Hakyll, a static site generator for Haskell inspired by Jekyll, which uses pandoc to generate HTML from Markdown. http://jaspervdj.be/hakyll/
For the author, typo on 'asking', " indicates an error, askign me to"
Yahoo don't care about the user experience. I hate the fact that flickr was bought by them and not Google. The requirement to have a Yahoo account to sign in to it is a bit of a joke, considering how their mail service might as well not exist any more.
[deleted]
No spaces in passwords? Obviously not hashing them.
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!
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!
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.
> 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.
> But why?
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.
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.
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.
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?
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?
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.
> 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.
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:
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.
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.
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.
Spaces are just characters. Their presence has nothing to do with hashing algorithms working or not.
That's the point; since spaces in the password cleartext should not matter for storing the password hash, what would be a good reason to disallow them?
There isn't one.
Which begs the question why I was downvoted heavily and posted to @shit_HN_says for making the comment.
How the hell should I know? But if I had to guess, I'd say it was because your prior comment implicitly equates "spaces prohibited in passwords" and "passwords not hashed" and assumes the latter as a necessary consequence of the former, when the two are entirely unrelated.
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.
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.
[deleted]
Should leading and trailing spaces be removed from input fields?
It's the lazy way of stopping users from cheating a minimum password length requirement.
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.
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.
Why are they obviously not hashing?
because if they were hashed, spaces would be irrelevant (hashes don't have spaces)
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
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.
[deleted]
its probably because of dumb users. user makes password with spaces, then tries with without spaces and cant figure out why it wont work...
I don't know why this is getting downvoted. It's pretty easy to have accidently insert leading or trailing whitespace when copying/pasting a password.
(Users should never store passwords in plain text or email them to one-another but the reality is they do.)
(Users should never store passwords in plain text or email them to one-another but the reality is they do.)
client-side validation?
There's a difference between not allowing spaces and not hashing. They could have just written a bad PW policy that doesn't completely make sense
You're drawing conclusions from information that doesn't lead you to one.
You're drawing conclusions from information that doesn't lead you to one.
Yahoo usernames were required in 2007: http://news.bbc.co.uk/2/hi/technology/6316761.stm