I really feel like SnapChat is fumbling this whole thing. They ignored the security warning, and now seem to be blaming the security group for the leak of info:
>On Christmas Eve, that same group publicly documented our API, making it easier for individuals to abuse our service and violate our Terms of Use.
The funny thing is that folks on HN and in the tech community generally will fault SnapChat for their callous attitude to security and pitiful response. But 99.9% of their users won't know or care, and investors will consider this a "lesson learned" and move on without a second thought.
Once the 24/hr news-cycle moves past the hyperbolic "SnapChat Hacked!" headlines, this ordeal and their pathetic response will slip into the forgotten-ether of low-impact data leaks.
>callous attitude to security and pitiful response
How would you have designed this functionality in a way that isn't vulnerable to the same attack?
Rate-limiting can slow you down, but you could run the script for months if you wanted. Fundamentally Snapchat is using user-supplied data, and users can lie.
Maybe we can check if they are lying by querying a database of people who have verified that they know each other? Oh wait, that's Facebook. HN would be boycotting on principle and screaming about violation of privacy.
You seem to take position to defend the snapchat stance ... I read it as a validation that there is a tradeoff made by design, and anyone caring enough about privacy wouldn't have implemented the feature in the first place.
Privacy doesn't have to be the goal of every service, let's just admit that it not a main concern of Snapchat either.
Of course Facebook also has a lot of leaky behaviors concerning finding friends and friend suggestion. They also value service growth more than privacy, and that's their right.
Put hard limits on the rate or total number of friend lookups per account, especially if a lookup fails. Keep track of global lookups and lock down the global lookup rate if there is a large number of failures. Keep track of patterns in lookups. Disallow more than a few lookups for accounts that haven't sent or received any messages. Require approval by the receiver for a lookup based on a phone number before the username is revealed. Charge money for phone number based lookups or require some sort of identification. Only allow phone number based lookups from within the smartphone app, not via the API.
And so on.
This is not rocket science, it requires mainly only that the devs legitimately care about security and privacy. But if the problem is instead approached by cavalier developers who are only reluctantly tackling the problem after having been burned by bad PR due to previous breaches then the result will often be half-assed engineering that does little to solve the problem.
The biggest issue for SnapChat is, to be frank, they are a bunch of dumb-asses who got lucky and managed to cobble together a silly app that a lot of people wanted to use. However, the foundation their app is built on is a degree of privacy, but that privacy is just an illusion, it is not based on any substantive engineering whatsoever and the SnapChat developers are too clueless to actually take on the problems that need tackling. This is just the first of what will ultimately be many failures at SnapChat which will ultimately reveal the trust placed in the company to be completely misplaced, causing their user base to evaporate. They should have taken the acquisition offer, at this rate the chances of their company being in ruins in a few months time is very, very high.
>Put hard limits on the rate or total number of friend lookups per account, especially if a lookup fails.
Easy: distribute the search across accounts. Also you'd expect most of the lookups to fail (most people in your contacts won't be Snapchat users).
> Keep track of global lookups and lock down the global lookup rate if there is a large number of failure
Again, you expect a large number of failures.
> Disallow more than a few lookups for accounts that haven't sent or received any messages.
Using the find friends functionality is intended to get you started with Snapchat. When you haven't sent many/any messages is when it matters most.
> Require approval by the receiver for a lookup based on a phone number before the username is revealed.
Many users (myself included) would consider notifications of this volume to be spam.
>Charge money for phone number based lookups
I don't know anyone who would pay to use Snapchat.
>require some sort of identification
Yeah, because requiring strong identification totally makes privacy advocates happy.
> Only allow phone number based lookups from within the smartphone app, not via the API.
Smartphone app has to communicate with Snapchat somehow, so the functionality is going to have to be exposed via an API. iOS is closed enough that you might be able to securely authenticate the app to the API, but AFAIK you can't stop the user from getting the key out of an Android app if he has root.
I can't comment on Snapchat's competence overall, but none of your solutions actually work. This is a nontrivial problem.
>The biggest issue for SnapChat is, to be frank, they are a bunch of dumb-asses who got lucky and managed to cobble together a silly app that a lot of people wanted to use. However, the foundation their app is built on is a degree of privacy, but that privacy is just an illusion, it is not based on any substantive engineering whatsoever and the SnapChat developers are too clueless to actually take on the problems that need tackling.
It depends on what kind of privacy you care about. Personally, I care very much about the privacy of my private communications (Facebook messages, emails, texts).
I don't consider usernames or phone numbers to be private information. Being able to find someone's contact info by name (and vice versa) is useful and people who make this difficult are just annoying. Failing to protect contact information is very different from failing to protect actual communications or metadata, and a callous attitude towards the security of contact information does not imply a callous attitude towards the security of communications.
There is a reasonable argument that a map between phone numbers and usernames could blow pseudonyms. But AFAIK most people use Snapchat with their friends - people who already have their names and phone numbers. If you reuse your Snapchat username somewhere where you want to be anonymous, you've already fucked up. Your cover is already blown. Whether it's blown to your friends or the whole world is a distinction without a difference.
AFAIK, it falls under PII. I realize some may not consider this personal info, but many others do. There are laws built around its protection and disclosure.
I think a failure to protect any data, including PII, is harmful to the user experience and a brand's image.
> Rate-limiting can slow you down, but you could run the script for months if you wanted. Fundamentally Snapchat is using user-supplied data, and users can lie.
You can make the same argument about employing exponential backoff on a login screen. It's still very effective deterrence.
There is a good chance that a failed password attempt is an indication of something shady going on, so exponential delays are appropriate.
How are you going to tell the difference between an API hit for the phone number of someone you know vs. a phone number you made up? Or are you going to increase the delay after every query? If you do that, then the "find friends" feature will just break down for people with sufficiently large contact lists.
Maybe don't reveal the username unless that user has your phone number in their contacts? Sounds good. But how are you going to check? Snapchat would need to store every user's contact list, which HN also considers unacceptable. Hashing is not an effective mitigator here because it's so easy to bruteforce the space of 10-digit numbers.
Maybe rate-limiting as such is not the right idea, but how about just limiting accounts? I think there is a substantial difference between the 4.6mm collected and even a "sufficiently large contact list." There must be a number at which you can be banned from requesting any more.
> Maybe don't reveal the username unless that user has your phone number in their contacts? Sounds good. But how are you going to check? Snapchat would need to store every user's contact list, which HN also considers unacceptable. Hashing is not an effective mitigator here because it's so easy to bruteforce the space of 10-digit numbers.
There's a partial fix to this that minimises what is stored by Snapchat. It does introduce a delay as it requires the other user to be logged in or eventually log in:-
User_A joins and has 10 numbers in his contacts list and Snapchat wants to find if they are friends (i.e. they both have each other's phone number in their contact lists). All 10 numbers are provided to Snapchat, only 5 numbers correspond to existing Snapchat users, the other 5 numbers are discarded by Snapchat. These remaining numbers, now linked to snapchat Usernames, then go into a table:-
When User_B next logs in the app checks for any people seeking connection with them; an API call returns a list of phone numbers which the app should check (i.e. User_B executing this would get the phone number of User_A) to see if they are in the local contact list (rather than uploading their entire contact list to Snapchat). If any numbers are in that list then they can be provided back to Snapchat and the server examines the table to find out which friends can be paired together, upon return of these results all rows for people seeking User_B will be either actioned (in User_B's contact list) or cleared (not in the contact list).
This means only a subset of a user's contact list is stored (the numbers that are known to use Snapchat), and only until the other party logs in, all of which is akin to an automated 'friend request'.
No persistent storage of all users' contact lists required, nor is there any need to store anything else about the contact list other than it contained the phone number of an existing Snapchat user.
Entries in this DB would timeout (pick an appropriate timeout) so they are not retained in perpetuity, new entries would only be created if the other user (i.e. User_B) has been active in Snapchat recently.
The app would also monitor for additions/modifications to the contact list on the phone and attempt new friend discovery by the same method. (This can be done via hashing, for each contact the app stores locally just a hash of the contact's information - name and phone numbers at least - and then on each startup (or at a certain interval) it compares the hashes it knows about with the hashes obtained from the current contact list, the friend discovery is then performed for any contacts relating to new hashes.)
User_A doesn't need to worry about missing users who join subsequently (i.e. one of the 5 numbers that were unknown to Snapchat when they first joined) as these will be handled by the subsequent user joining and going through this same process.
There aren't great simple solutions to this issue AFAIK, but here's my take since I had a similar android app feature:
Want to find friends using contacts in phone:
Snapchat solution: pass number(s), return user info if number(s) in DB. +rate limit
Problem: rate limiting is not enough in this case.
Other solution:
Save contact lists of two users. If user requests friend look up, compare contact lists.
Basically return user info if the two numbers have each other in contact list, thus a verification they know each other.
Duping the snapchat system with the old method won't work, but drawbacks are that you have to store
a copy of user sensitive information, and if that gets out from your servers in some other hack, that would be
really bad, as bad if not worse than the first since it has more information, i.e. who knows who. Also less efficient,
space and time wise.
HN maintains that this is unethical because the users in your contact list have not consented to having their phone numbers shared with a social networking service.
You could use a key derivation function (scrypt or pbkdf2) to expand it out and make it quite difficult to even rainbow table it. You could also compound the effort by only storing a hash of the pairs (one hash or derived key of two phone numbers) with no associated metadata directly linked to it, only as an access gate. Collisions may occur but at least the positive results from a total search space would be significantly reduced.
I Am Not A Cryptographer, so I admit there is likely faulty reasoning in there somewhere, though.
The point is that the hash is effectively reversible at that scale. 10 numeric digits is 10 billion possibilities. It's actually far less than that because area codes don't span the entire 3-digit number range, and most area codes are not heavily populated. But even so, creating a lookup table by computing 10 billion hashes is today a comparatively easy task, even for expensive hash algorithms. It's a matter of only a few seconds to minutes work with relatively common hardware (high performance GPUs).
If only it would go away so easily. The PR strategy they have going on, if taken at face value, is a sure way to have stuff like this happen again; and every time they'll be the losers. Pissing off the same people who are trying to help you is childish at best.
Exactly. Getting individual users to care about privacy or security is ultimately a cultural thing. In the US (which probably has most of Snapchat's users), the attitude of the general public to this seems to be pretty gung-ho, leading to this being a non-event.
I suspect (but can't be sure) that if something like this happened, in, say, Germany, it would generate far more impact and press attention. Most of my US acquaintances who are college students don't give two hoots about privacy -- they are far too busy marketing themselves to the world as much as possible.
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.
Wow. Talk about a non-reaction. As if bad code resulting in the disclosure of 4.6MM numbers and IDs is a non-issue.
Posted something about this on FB, achieved zero reactions which really surprised me, until I realized that some think it's only for sexting... and thus nobody is willing to admit they've installed it (it's useful for other stuff as well, I'm my own emoticon).
Several of my friends are in the list (known nicks match known numbers, showing exactly what's the problem here).
I'm in college, and I would say 95% of my friends have snapchat. Most of them use it at least once a day. Nobody sends naked pics. Just stuff that you wouldn't necessarily post to facebook. Snapchat's reputation as naked pics only is completely unfounded... it's not like they're sending 450mm nudes every day.
EDIT: hey' where's the response I was responding to?
Obviously (obviously!) I don't use it for sex pix. Never trusted the "no screenshot possible" aspect, nor does my wife...
Anyhow, I dismissed it as useless for that exact same reason, but I have a bunch of friends that I send silly messages to and like I said, it works quite well if you use your own face as an emoticon.
We also like the paint-over the picture feature. It's easy to add odd picture annotations (stick figure skiers in the snow, cowboys and indians) and then send cartoons back and forth.
It also has practical uses, because you can save the picture before sending. The other day I was in the market for window shades -- I know, so very Burbistan -- so I took a shot of each window in my home, marked up every picture with the dimensions and saved it to my phone (my friends have no interest in 18 sets of window dimensions)
Best of all, all this nonsense doesn't take up any space on my phone.
There is an easier way to solve this issue: Bug Bounty.
It worked for Google, it worked for Facebook and its working for Yahoo! Infact, it worked so well for Google that they recently increased the rewards. A venture-backed startup like Snapchat that stores private pictures (even temporarily) should have no trouble paying out $5k a few times for vulnerabities.
The problem is they did not see it as a vulnerability, they touted it as a feature, and even made a blog post outlining how you could exploit it. That was the most WTF event in following this story.
I mean, do phonebooks still exist? They used to list everyone's numbers and their names and addresses and then leave them on everyone's doorstep. This is just a (partial) phone number and username.
About the worst abuse I can think of is that you have someone's username from another service, and you can maybe find their phone number.
This seems mild compared to, say, Facebook allowing you to search by email and find a user's facebook profile.
Why is user info presented in the clear to anyone who asks for it via their api?
Here's a more sane approach I imagine:
Allow sending snaps to a phone number (rather than to a username - since you would not know it the time), and attach a "friend request" as part of delivery. When the person at that phone number retrieves the snap they have the additional option of accepting the friend request which then (and only then) exposes their user info to the originating party.
Leave out the snap sending part, just make it a friend request. Don't expose to the sender whether the number is not attached to account, it is accepted or rejected. User can or can not send snaps then.
No, via snapchat's delivery system; they obviously can map a phone number to username, therefor they can implement sending snaps to phone numbers (as a proxy) in place of a username.
That is one of the worst 'apologies' from I startup I've ever read.
There is none " We fucked up, sorry, we're fixing it". They speak of the leak as simple 'hack' like someone who was capable of finding all your friends using facebook and random luck.
I hope they fix this right, and be more apologetic the next time.
A 322 word blog post, no apology and 6 instances of the word 'abuse'.
The PR message that Snapchat just sent is not a good one. Their target demographic may not care much, but at the end of the day, this brand just dropped a big ball and lost an opportunity to build something better.
So in a nutshell they are saying that some of their users are risky enough to use a feature that discloses their phone number to them, and they consider this information as non-sensitive data.
Snapchat is and will always just be a fad, it's the current social network flavour of the time, and when something more interesting comes along, I will bet that the 4.6M users will be inactive in no time.
This is also why their users aren't concerned with this leak, because the premise in snapchat is a sort of leaking of your good and bad moments, with no filter.
But i'd be pretty sure that if it turns out they save the images and videos, it would be much bigger of a deal, because it ruins this premise.
"We want to make sure that security experts can get ahold of us when they discover new ways to abuse our service so that we can respond quickly to address those concerns."
>On Christmas Eve, that same group publicly documented our API, making it easier for individuals to abuse our service and violate our Terms of Use.
The funny thing is that folks on HN and in the tech community generally will fault SnapChat for their callous attitude to security and pitiful response. But 99.9% of their users won't know or care, and investors will consider this a "lesson learned" and move on without a second thought.
Once the 24/hr news-cycle moves past the hyperbolic "SnapChat Hacked!" headlines, this ordeal and their pathetic response will slip into the forgotten-ether of low-impact data leaks.