Hashes never increase the amount of information that's present, thus if there are 10^10 possible phone numbers, there are 10^10 possible hashes of phone numbers (with a given algorithm). How many bits you encode the information in doesn't matter.
The only way you can stop this attack is by rate limiting (I would use some sort of exponential slowdown based on number of requests in a given period) or by not doing it in the first place. It's not hard to determine that if you have a function X -> Y, you can find all the Ys by putting in all the Xs, and correlate the two; that's what's happening here, and it's a privacy trade-off, but not a security issue.
I'm not certain what jluxenberg is proposing with the hashes. But one possibility is that the exposed API will accept hashes that only the app can generate (through a salt). Although obviously you can crack the app, I suspect this is significantly harder.
Comments
Hashes never increase the amount of information that's present, thus if there are 10^10 possible phone numbers, there are 10^10 possible hashes of phone numbers (with a given algorithm). How many bits you encode the information in doesn't matter.
The only way you can stop this attack is by rate limiting (I would use some sort of exponential slowdown based on number of requests in a given period) or by not doing it in the first place. It's not hard to determine that if you have a function X -> Y, you can find all the Ys by putting in all the Xs, and correlate the two; that's what's happening here, and it's a privacy trade-off, but not a security issue.
I'm not certain what jluxenberg is proposing with the hashes. But one possibility is that the exposed API will accept hashes that only the app can generate (through a salt). Although obviously you can crack the app, I suspect this is significantly harder.