I implemented a "find friends" server side functionality for a mobile app (due to a similar business requirement of allowing new users to locate friends).
After prompting the user for the ok, the mobile app would upload the entire address book to the server. I would check for matches and return a maximum of 25% of total contacts as being valid (randomly so you wouldn't know which numbers really didn't exist). If there were more hits they would be placed into a queue and sent periodically as "your friend has joined!" notices which also increased engagement.
Subsequent checks were done by again uploading the entire address book, however I would check against the previously stored phonebook (numbers only hashed with a per user salt) and limit the number of valid hits returned based on the delta of the address book. So if you kept sending 1000 new numbers every time, you wouldn't get any new matches.
It was also rate limited per account (which required a verified phone number). All the logic took less than a few hours to think up and implement. Here you go Snapchat, now fix your shit.
At least you ask the user for permission- Snapchat doesn't even alert the user before uploading the ENTIRE address book!
I take issue with this new generation of developers who seem to have no moral or ethical boundaries on the invasion of privacy.
The whole "viral/social marketing" trend is also to blame, in addition to the way that startup valuation puts so much emphasis on "traction" rather than the actual tech or even a viable business model!
I take issue with this new generation of developers who seem to have no moral or ethical boundaries on the invasion of privacy.
I do too, but I'm beginning to become convinced that most people really don't care and really aren't bothered by it.
We've had numerous clients -- maybe most of them -- request or expect us to keep track of the passwords for their online accounts for them. Privacy erosions and violations by various businesses really haven't been that big of a deal outside of tech circles. Just an hour or so ago, while on an errand, an NPR guest was mentioning something similar, that her Facebook account had been compromised but it didn't change the way she used the service. It wasn't really anything more than a temporary inconvenience for her.
Earlier today, a client's personal Hotmail account was compromised. It was being used to spam people on his contacts list. We got in touch with him to give him the heads-up on it. His response was, "it's not a big deal, I don't really care about that, I'm not even going to change the password on it."
We had one business client that supposedly took security very seriously. Government funded and all that. They would routinely ask us to put new procedures and safeguards in place, only to then turn around and immediately try to work around them for convenience's sake.
This has been a tough thing to accept, but I really don't believe any more that most people care at all about privacy or security. What they mostly want is convenience.
This isn't an issue with convenience, this is an issue with Snapchat failing to fix a vulnerability.
How relevant is find_friends to Snapchat now? Is it really needed? Are they getting that many users building relationships for it? Is it worth damaging Snapchats image?
Not true; they prompt and clearly describe what they will do with your address book during onboarding. Can't find a screenshot of it now, and maybe it has changed since they first launched.
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.
Tangential, but: we only have "find friends" by email, not phone, but we use a one-way hash of the email for the request so that our servers don't get sent emails that we don't already have, which helps a little though not with the SnapChat issue.
Comments
I implemented a "find friends" server side functionality for a mobile app (due to a similar business requirement of allowing new users to locate friends).
After prompting the user for the ok, the mobile app would upload the entire address book to the server. I would check for matches and return a maximum of 25% of total contacts as being valid (randomly so you wouldn't know which numbers really didn't exist). If there were more hits they would be placed into a queue and sent periodically as "your friend has joined!" notices which also increased engagement.
Subsequent checks were done by again uploading the entire address book, however I would check against the previously stored phonebook (numbers only hashed with a per user salt) and limit the number of valid hits returned based on the delta of the address book. So if you kept sending 1000 new numbers every time, you wouldn't get any new matches.
It was also rate limited per account (which required a verified phone number). All the logic took less than a few hours to think up and implement. Here you go Snapchat, now fix your shit.
At least you ask the user for permission- Snapchat doesn't even alert the user before uploading the ENTIRE address book!
I take issue with this new generation of developers who seem to have no moral or ethical boundaries on the invasion of privacy.
The whole "viral/social marketing" trend is also to blame, in addition to the way that startup valuation puts so much emphasis on "traction" rather than the actual tech or even a viable business model!
I do too, but I'm beginning to become convinced that most people really don't care and really aren't bothered by it.
We've had numerous clients -- maybe most of them -- request or expect us to keep track of the passwords for their online accounts for them. Privacy erosions and violations by various businesses really haven't been that big of a deal outside of tech circles. Just an hour or so ago, while on an errand, an NPR guest was mentioning something similar, that her Facebook account had been compromised but it didn't change the way she used the service. It wasn't really anything more than a temporary inconvenience for her.
Earlier today, a client's personal Hotmail account was compromised. It was being used to spam people on his contacts list. We got in touch with him to give him the heads-up on it. His response was, "it's not a big deal, I don't really care about that, I'm not even going to change the password on it."
We had one business client that supposedly took security very seriously. Government funded and all that. They would routinely ask us to put new procedures and safeguards in place, only to then turn around and immediately try to work around them for convenience's sake.
This has been a tough thing to accept, but I really don't believe any more that most people care at all about privacy or security. What they mostly want is convenience.
And SnapChat is very convenient.
This isn't an issue with convenience, this is an issue with Snapchat failing to fix a vulnerability.
How relevant is find_friends to Snapchat now? Is it really needed? Are they getting that many users building relationships for it? Is it worth damaging Snapchats image?
I don't think you fully grasped what I was saying.
This won't damage SnapChat's image. At least, not among most of their userbase.
They don't need to focus on fixing this or on coming up with a better response because this isn't important to enough people.
They won't see a huge amount of users deleting accounts, but I'm sure future users will think twice before joining.
Also, the value of the company.
Not true; they prompt and clearly describe what they will do with your address book during onboarding. Can't find a screenshot of it now, and maybe it has changed since they first launched.
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.
Tangential, but: we only have "find friends" by email, not phone, but we use a one-way hash of the email for the request so that our servers don't get sent emails that we don't already have, which helps a little though not with the SnapChat issue.