I think hashing is key here. There are 10^10 possible phone numbers (without country code), so approx 34 bits of information to encode the entire phone number space.
If your API accepts a 128-bit hash (pick your favorite) of a phone number and returns the user's username, and is rate-limited, it would be infeasible to brute force the hashed phone number space to produce the data dump. Then, rate limit by account (rather than IP address) and flag accounts accessing this API too frequently or in different patterns than your client uses.
You're assuming that the hashing algo used in the app is indecipherable by an attacker - if the hashing algo used is known, then the attacker does the same as done in this SnapChat attack, except just hashing the number first.
One typically uses salting to randomly generate a hash function. (so even if you know it was, say, SHA512, you have to guess the salt to reverse engineer)
No matter what you do, you're running that code on the client application, so it would then fall back on relying on code obfuscation unless I'm missing something.
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
I think hashing is key here. There are 10^10 possible phone numbers (without country code), so approx 34 bits of information to encode the entire phone number space.
If your API accepts a 128-bit hash (pick your favorite) of a phone number and returns the user's username, and is rate-limited, it would be infeasible to brute force the hashed phone number space to produce the data dump. Then, rate limit by account (rather than IP address) and flag accounts accessing this API too frequently or in different patterns than your client uses.
You're assuming that the hashing algo used in the app is indecipherable by an attacker - if the hashing algo used is known, then the attacker does the same as done in this SnapChat attack, except just hashing the number first.
One typically uses salting to randomly generate a hash function. (so even if you know it was, say, SHA512, you have to guess the salt to reverse engineer)
No matter what you do, you're running that code on the client application, so it would then fall back on relying on code obfuscation unless I'm missing something.
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.