Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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.


Got it. That makes sense.


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


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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: