Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I will never be able to log in to Flickr again

ngzhian.github.io

Post reply on HN
Print view View original

21–30 of 43 posts

Re: I will never be able to log in to Flickr again

#21

Post by nwh »

arcticPeril wrote: post #16
nwh wrote: post #6

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…

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.

Re: I will never be able to log in to Flickr again

#22

Post by conectorx »

freditup wrote: post #4

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

so, just because everybody does it you think is right?... I agree to disagree.

Re: I will never be able to log in to Flickr again

#23

Post by nwh »

aaronem wrote: post #20
PavlovsCat wrote: post #15

Earlier quoted context omitted.

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.

Re: I will never be able to log in to Flickr again

#24

Post by pooper »

usablebytes wrote: post #18

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

Re: I will never be able to log in to Flickr again

#25

Post by arcticPeril »

nwh wrote: post #21
arcticPeril wrote: post #16

Earlier quoted context omitted.

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…

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 d…

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

Re: I will never be able to log in to Flickr again

#26

Post by DerpDerpDerp »

usablebytes wrote: post #18

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.

My bank insisting on a hard-to-remember 8 character password isn't make it more secure than letting me pick a longer passphrase.

Re: I will never be able to log in to Flickr again

#27

Post by nwh »

arcticPeril wrote: post #25
nwh wrote: post #21

Earlier quoted context omitted.

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 d…

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

Re: I will never be able to log in to Flickr again

#29

Post by arcticPeril »

nwh wrote: post #27
arcticPeril wrote: post #25

Earlier 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…

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?

Re: I will never be able to log in to Flickr again

#30

Post by taspeotis »

tomschlick wrote: post #17
iancarroll wrote: post #9

Earlier quoted context omitted.

because if they were hashed, spaces would be irrelevant (hashes don't have spaces)

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

Post reply on HN