15

I'm working on a REST service that has a few requirements:

  1. It has to be secure.
  2. Users should not be able to forge requests.

My current proposed solution is to have a custom Authorization header that look like this (this is the same way that the amazon web services work):

Authorization: MYAPI username:signature

My question is how to form the signature. When the user logs into the service they are given a secret key which they should be able to use to sign requests. This will stop other users submitting requests on their behalf, but will not stop them forging requests.

The application that will be using this service is an iPhone application, so I was thinking we could have a public key embedded in the application which we can do an additional signature with, but does this mean we'll have to have two signatures, one for the user key and one for the app key?

Any advice would be greatly appreciated, I'd quite like to get this right the first time.

Jakub Kubrynski
  • 13,724
  • 6
  • 60
  • 85
jonnii
  • 28,019
  • 8
  • 80
  • 108

4 Answers4

8

The answer is simple: It cannot be done. As soon as you ship any solution to the end user, he or she can allways attack the server it is communicating with. The most common version of this problem is cheating with hi-score lists in Flash games. You can make it harder by embedding some sort of encryption in the client and obfuscating the code... But all compiled and obfuscated code can allways be decompiled and unobfuscated. It is just a matter of how much time and money you are willing to spend and likewise for the potential attacker.

So your concern is not how to try to prevent the user from sending faulty data to your system. It is how to prevent the user from damaging your system. You have to design your interfaces so that all damage done by faulty data only affects the user sending it.

Johan Öbrink
  • 1,241
  • 1
  • 11
  • 17
  • In this case we're going to be deploying to the iphone, so there is a risk of someone decompiling the code. You raise very valid points in your post about limiting the ability to damage only that users data, in this case they'd be able to cheat in a game, so we need to be able to identify cheaters and deal with them effectively. No easy task. – jonnii May 01 '09 at 17:47
  • The only way to secure av game is to run it entirely ön the server and only sending the users actions over the wire. What I usually do is: 1. Make cheating difficult 2. Save as much information as possible. Cheating is usually reasonably easy to spot so you can delete all entries for that user afterwards. – Johan Öbrink May 01 '09 at 19:23
  • If you are developing a GAME, and this is a CHEATING problem, then you have a whole other host of tools available to you - depending on whether it's a game of skill or game of chance. Generally speaking, player performance can be measured statistically and strange patterns can be spotted - that's how many fraud detection systems work in the entertainment industry. Another thing that instantly comes to mind is algorithmic design which introduces certain measurable properties to the game - for example, error accumulation in floating point numbers. – mst Dec 29 '09 at 17:03
2

What's wrong with HTTP Digest Authentication?

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • Firstly I'm going to have to use SSL for the requests (which is fine), but it doesn't stop a user logging into the API from a non iPhone device and submitting forged requests. – jonnii Oct 27 '08 at 15:40
  • How can they forge a request via digest authentication? How did they get the current nonce value and create an acceptable digest response? – S.Lott Oct 27 '08 at 16:03
  • They can forge a request because they can create a 3rd party client application that logs into the api, at which point they can submit their own requests. I need to verify the source of the api request. – jonnii Oct 27 '08 at 16:13
  • Why can't you use a client nonce in the response which is a signature string unique to each iPhone? – S.Lott Oct 27 '08 at 16:25
  • When the user logs in we get their device id, so that might work. I'll investigate this and see what I come up with. – jonnii Oct 27 '08 at 16:42
  • If you can read the device id, so can the attacker. It is no complete protection. It does however make the attack difficult which might be good enough. Combine it with extensive logging and you should be able to identify cheating and delete all entries for (and block?) that user. – Johan Öbrink May 01 '09 at 19:30
1

I think the simplest way to do this right would be to use HTTPS client authentication. Apple's site has a thread on this very subject.

Edit: to handle authorization, I would create a separate resource (URI) on the server for each user, and only permit that (authenticated) user to manipulate this resource.

Edit (2014): Apple changed their forum software in the past six years; the thread is now at https://discussions.apple.com/thread/1643618

Steven Huwig
  • 20,015
  • 9
  • 55
  • 79
  • How does this stop users from forging requests? – jonnii Oct 27 '08 at 15:35
  • HTTPS client authentication requires the client to have a valid public key certificate. Unless you mean by "forging requests" that an authenticated user is somehow making unauthorized requests, which is an authorization problem not an authentication problem. – Steven Huwig Oct 27 '08 at 16:55
  • That's the problem i'm trying to address, I updated the topic to reflect this. How would you suggest authorizing valid requests? – jonnii Oct 27 '08 at 17:29
  • @PeterMorris You're going to -1 because of a dead link on a six-year-old answer? Nice. – Steven Huwig Oct 31 '14 at 14:47
  • @StevenHuwig Yes. The purpose is to attract the poster (you) back so that you can fix your answer, and then when you comment saying "Thanks, I've fixed it" I remove the -1. It's a quality control practice, nothing more :) – Peter Morris Oct 31 '14 at 19:17
  • 1
    It seems more constructive to take the thirty seconds that I took to track down the original link and post it in a comment or an edit. – Steven Huwig Oct 31 '14 at 19:18
  • Steven, please understand that I am only trying to be helpful. The fact this answer was posted 6 years ago is irrelevant. So is the fact that you had the same problem 2 years ago and fixed it. The problem is that it is broken today. Perhaps you could consider quoting the relevant parts from the link on future answers? That way the broken link wouldn't even be relevant (I've seen this approach suggested). In the meantime, what you do about this is your choice, I only wanted to let you know. – Peter Morris Oct 31 '14 at 20:00
  • Steven, if you'd like to email me to discuss this (mrpmorris at gmail) you can, or get hold of me on Skype (mrpmorris) - my actions are not malicious. – Peter Morris Oct 31 '14 at 20:27
  • 1
    @PeterMorris There is nothing to discuss; you are ignoring the clearly stated purpose of downvotes, and of course I can do nothing to stop it. Your intentions are irrelevant. http://stackoverflow.com/help/privileges/vote-down - "Use your downvotes whenever you encounter an egregiously sloppy, no-effort-expended post, or an answer that is clearly and perhaps dangerously incorrect." – Steven Huwig Oct 31 '14 at 21:48
  • And what are your intentions on going through my answers and down voting them? Are they in keeping with the link you posted? – Peter Morris Oct 31 '14 at 23:56
  • They are in keeping with your approach to this affair, so if you dislike that approach I suggest you adjust it. – Steven Huwig Nov 01 '14 at 02:01
1

There is a better discussion of this here:

Best Practices for securing a REST API / web service

Community
  • 1
  • 1
jonnii
  • 28,019
  • 8
  • 80
  • 108