5

I have never used Snapchat and do not intend to but I have been reading up about what happened to them with respect to the recent media coverage about pictures being leaked especially because I am also writing an api for my app right now and I want to avoid this from ever happening to me.

Having looked into what happened it seems Snapchat has not actually done anything wrong. It appears a third party web app sniffed out their api calls - not something to be surprised about, anyone can do it, and that's why apis should require authentication, how this is done can vary but probably through some kind of token.

In any case, Snapchat api did require authentication so I thought they would have been safe but it turns out that the third party apps got users to voluntarily enter their usernames and passwords into the app, thereby allowing login and authentication.

Remember this was a third party app, not the official snapchat app. I would never have expected users to do something like this, it's like giving away the keys to your car to anyone who passes by instead of the hotel valet.

Now to the point, are they any techniques to avoid this from happening that I can apply for my api? I am not sure how I can prevent myself from ending up in the same situation.

7
  • 9
    I haven't been following this as closely as you, but it sounds like the 3rd-party use of the snapchat API succeeded because of successful social engineering. No matter how good your code is, it's hard to code against social engineering. Commented Oct 16, 2014 at 17:10
  • When you wrote that the private API calls need to require authentication, I agreed. But it seems we were thinking of different things. A private API call, i.e. an action that 3rd party apps should not be able to use, should demand authentication of the app, via an API key or something similar, regardless of whether the action being performed also requires user authentication.
    – user7043
    Commented Oct 16, 2014 at 17:16
  • Sure, tell your users to not log into a third party site using their username and password. That should take care of your API abuse problems.
    – Ampt
    Commented Oct 16, 2014 at 17:19
  • 2
    @Ampt Gosh, it's too bad Snapchat never thought of that! Commented Oct 16, 2014 at 17:45
  • 1
    @FrustratedWithFormsDesigner I know right? All that technical know-how brought down by users just giving out their passwords to strangers on the web. For shame snapchat!
    – Ampt
    Commented Oct 16, 2014 at 17:46

2 Answers 2

6

It is impossible to prevent this issue from happening completely. There are two things you can do that will help but not completely migrate the problem:

  • Use SSL only: If you control both the client and the server than there is no reason you can't encrypt the traffic, this prevents people from sniffing out your API calls by studying your traffic - it also protects user secrets and help prevent man-in-the-middle attacks.

  • Use a Api Key. This should be a hidden key that can be attached to transactions that validates that the API call came from an approved application. Note that this is only useful if the traffic is encrypted, since the key is useless if it's visible over plain text.

Again, it is not possible to protect oneself completely as the nature of the web is pretty insecure. It wasn't built with security in mind initially so you should assume that anything exposed publicly can/will be used by another party at some point.

3
  • I am/will be doing both of these. However the problem is that api key (such as a json web token) can be got from the service (Api) if the call is to login with a username and password. After that any api call will be considered authenticated. Browsers have some security with their cookies I believe with the same origin requirements but I'm primarily interested in mobile apps and a separate service.
    – ajeetdl
    Commented Oct 16, 2014 at 23:32
  • Bear in mind this would be separate and in addition to the Oauth key. The Oauth key allows you to track login information but isn't secure.
    – ChargerIIC
    Commented Oct 16, 2014 at 23:41
  • Then what does OAuth do? they have a SSO page and seems nobody can forge it. Commented Feb 9, 2021 at 20:14
0

One possible solution (but with a small trade-off) would be to limit the number of valid tokens a specific user is allowed to have at any given time. This will not STOP a third party's ability to access the site, however it would introduce a level of annoyance for a user that is using your API in an inappropriate way. If you set this limit to 1, then when the 3rd party app logs into the user's account, it would deauthorize any other sessions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.