Hacker News Reader

Comment by zxcmx | Hacker News Reader

My apologies, I was wrong. I was assuming that you were terminating ssl and therefore in a position to read the plaintext of user requests.

This would allow you to simply look up whether the password was pwned based on form submits.

[edit] ok, I understand what you are saying, Troy's service allows some password privacy due to api design and happens to use cloudflare stuff. Sorry I was so slow.

I was conflating two unrelated things; a) what happens when you submit a password through cloudflare and b) what happens when you happen to use a specific password checking api which uses cloudflare.

View on HN

I guess you didn't read his notation in the beginning of the article that you should read his previous posts on the subject. The whole point is that you give only a part (5 first characters) of the hash (SHA-1 in this case if I'm not mistaken?) to the API, and you are then returned a list of passwords with the same first characters, then you check that response against the actual password.

In effect, Troy's service never knows the password. It doesn't even know if it existed in the list you received.

Troy's API doesn't work like that. Doesn't need to send the password at all.

Wonderful, thank you [edit] thinking this through.... but regardless of how the api works, is it not possible that you (cloudflare) could just have the list and check yourselves since you know the submitted password?

It could be a value added service for all your customers.

[Sorry for the late edit, not being evil here].

The entire dataset is available for download, so everyone can do the check themselves if they want to.

If you read the details of Troy's API you'll see that at no time does the password or even a hash of the password leave the computer of the person using the API.

Yep, I was sort of on the wrong tack. The api is fine, it just seems like an unnecessary dance for cloudflare integrated services since you have the password anyway.

What do you mean? It still sends a portion of the hash, not the whole password, but that's still some information, no? An attacker brute-forcing hashes doesn't care if he finds the exact hash or a set of a thousand he can try. In fact, since the database is public, if I have your range and the password is in it, I only have to try a few hundred passwords at most to find which one yours is. Granted, I also need to know which service you're using this on, but that doesn't seem that hard to find out.

I think the scenario you are describing is the following: the attacker somehow gets the hash submitted to the API and then runs JtR or similar to crack the password.

That doesn't work because only the first five characters of the hash are sent to the API. The API then returns a list of all the hashes that have that prefix that it knows about. The client then (privately) is able to see if their password hash is in that list.

No, it's more like "attacker gets the range, sends it to the API, gets all the possible hashes from the API, tries the corresponding plaintext passwords, thus needs only ~200 tries instead of X million".

Granted, your password was compromised already if it was in that list, so it needs to be changed anyway, but there's some information revealed by the hash (of course, how else could it be checked?).

Got it. That makes sense.

But the whole point of the api is that you don't use the password if it is found in the list. So the attacker will know about the 200 strings that are definitely not the password.

Assuming you managed to instantly change the password on every single service you've used it, yes.

Nobody is talking about it, but to compromise someone, you also need the username, which is not sent.

Ah, that's true. In any case, I don't think this is really a reasonable vector of attack, I was just being pedantic at jgc's "the password is not sent" comment.

You send a truncated digest of the password, which was obtained using a somewhat dubious hash function. I guess there are currently no known preimage attacks on this scheme, but revealing this information is more than nothing.

Reply on news.ycombinator.com