Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We have a web service logging/recording user data sent over https by our client application. Is there a way to securely ensure that the data is getting sent by the client application and not by a fake tool impersonating our app? Ideally, I wouldn't like to have to resort to things like hiding an obfuscated key in the client or other “security through secrecy” techniques…

share|improve this question
    
What type of data is being sent from the application ( as in is it XML or anything like that )? Does it have a consistent structure? –  Mark Davidson Nov 26 '10 at 9:24
    
It's zipped JSON, signed with a public key the app contains. But anyone could find the key and then forge a fake message… –  JPP Nov 26 '10 at 9:37
add comment

5 Answers

up vote 12 down vote accepted

You can't. A server fundamentally can't trust a client (there are some exceptions - if the client machine is hardened (hardware verifies firmware, firmware verifies OS, OS verifies every application running), it might be possible to do that (but not really - someone with a soldering iron could always modify the hardware verification), but if you don't 100% control the client, you're kinda out of luck.

You need to ask yourself: What are the risks of the client uploading bogus data? What are the consequences of not authenticating that it's your application uploading the data? One hard question you should ask: Does the client have an incentive to upload bogus data? If the user doesn't have an incentive to upload bogus data, they probably won't bother.

One thing that you can do: You can authenticate the user running the application (via any one of a number of authentication mechanisms) and then save the uploaded data along with the authenticated user ID (and IP address). That way if the user does upload bogus data, you can track back who made the change. Of course you've now made the data PII which may have privacy issues for your service.

share|improve this answer
add comment

You do need to authenticate the client, and that requires there to be some sort of secret. If a human user is controlling the client, you may just be able to register and authenticate the user, using some secret they know or have access to.

If the client is automated and you don't control the hardware and software environment that the client relies on, you're out of luck in the face of a determined attacker who has control of the client. But you can make it hard.

Your problem seems related to the general problem of licensing client applications, and a good overview of one approach to that (for android apps, in Java) is here:

http://android-developers.blogspot.com/2010/09/securing-android-lvl-applications.html

You can adapt that to your environment or look for other open source libraries suited to your situation.

By the way, "security via secrecy" is fine - secrets like private keys are part of most good schemes. It is "Security thru obscurity" that people try to avoid, i.e. just making things complicated, or pretending that attackers won't understand your algorithms.

share|improve this answer
    
+1 for "security via secrecy" vs. "security through obscurity" –  gowenfawr Aug 7 '13 at 17:14
add comment

If you take a look at the 10 immutable laws of security, law #3 explains the problem at a fundamental level:

Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore

share|improve this answer
add comment

You could use kerberos to perform mutual authentication between client and server. You would preferably have some out-of-band method for initially identifying the client, e.g. issuing the user with an identifier. of course, you now rely on that identifier not being compromised...

share|improve this answer
1  
Kerberos is no better than anything else when the client is rogue. –  Luc Oct 9 '12 at 15:19
add comment

As the other guys said, you cannot trust a client, until the client authenticates with a cert YOU created. At this moment the whole problem boils down to a key/cert distribution problem:

  1. How does the client know that it's getting a good cert from a real server?
  2. How does the server know that it's not giving away good certs to malicious clients?

Until these questions are answered (correctly!) all other events following the authentication are moot.

share|improve this answer
1  
Even using a certificate does not ensure that it is the correct application using the cert, and not a user that extracted the cert and is using it directly himself. –  AviD Nov 28 '10 at 13:33
    
@AviD Yes, that's precisely the problem. –  JPP Nov 29 '10 at 9:39
    
No it doesn't have to be a cert you created - it can be a cert signed by a trusted third party, or you can restrict access based on the hash of the public key of any cert if you get the client to send you the cert by secure means (but that presupposes that the client can ensure the security of the private cert) –  symcbean Nov 30 '10 at 16:55
    
@symcbean: "that presupposes that the client can ensure the security of the private cert" Yes, and again, that's the problem. I don't trust the human client; ideally, I would like to have a way to trust my app, and be sure that scenarios like "the guy extracted my trusted cert from my app and used it" cannot happen. Looks like it's fundamentally impossible, though. Sigh… –  JPP Dec 1 '10 at 9:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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