4

In our application, a user selects answers to questions. Their score is based on the time spent answering each question down to a tenth of a second. The server is responsible for calculating and storing the score, but it obviously cannot record the exact time spent itsself due to latency.

Somehow, the mobile app will have to send the server the time it took for them to answer the question according to it's own clock. How do I verify that the value in that API call is not being forged?

I figure that at the very least, we can have a string that is hardcoded into both applications that will encrypt/decrypt the timestamps (is AES good for this?) but this is not 100% secure as someone could manage to get that string through decompilation or whatever.

After that, I reckon we could measure the latency in a test request when we first communicate with the mobile app. Then we can ensure the times being sent are within a reasonable window based on that latency. To me this seems kind of finicky and inaccurate. It would be tough to decide on what the window would be since the values are so small. For example, if it took "5s" to answer a question with ~200ms latency, is the window 6? 7? 10? If the window is too large, forgery would still be worth it. Too small and you might screw over legit users who just had a second of lag or whatever.

Is there any robust solution? Would the encryption/decryption be "safe enough"?

|improve this question
  • You are asking about how to have assurance over a system you do not control, you may control the app, but do you control the system? – Eric G May 1 '14 at 2:03
  • Yes, that is why I'm asking. – Logan Serman May 1 '14 at 2:30
  • 2
    There's no way to secure this from a determined cheater - as you've noted, they can perform their own encryption. Heck, at that point they could supply their own timestamps; witness all the "high scores" for Angry Birds (or other games) in the iOS leaderboards. This also applies to estimating latency - you'd need a round trip to do this, which means waiting for the client to respond (see the problem there?). In short, nothing you can do will prevent people from submitting false information, the only thing to trust is your server. Duration is sending question to receiving answer. – Clockwork-Muse May 2 '14 at 1:43
2

As others have noted you can never trust the client, ever. You can make it difficult for people but there will always be attacks they can perform:

  • Artificially inflate measure of round trip time (RTT)
  • Extract encryption keys
  • Alter local clocks

Monitoring for suspicious behavior / timing irregularities may be possible though extremely difficult. For example what are typical RTT for people on a certain network / location and what is the typical variance in this? (e.g. statistical anomaly detection: http://en.wikipedia.org/wiki/Anomaly_detection )

A combination of making it hard and detecting anomalies would probably be the best you can do such that someone goes to a lot of effort, and then gets their scores wiped and account suspended for a while - similar to failing a doping test...

|improve this answer
0

I wouldn't use symmetric encryption, for the reason you say: one could extract this key. You could store the time frames locally, and have this sent using asymmetric encryption;

  1. the request is encrypted using the servers public key; so one cannot to a MitM to change their timestamps.
  2. your client 'signs' the request, so you're sure* that it's from the client.

*: you can only be as sure until somebody reverse engineers their application, and extract the private key from your app. The best (if not only) way again this would be to obfuscate this information; create a key upon app initialization, store it encrypted/encoded/obfuscated... and employ anti debugging techniques.

Even if one extracts the key, you could revoke that user's certificate and it won't jeopardize the rest.

|improve this answer
  • Er, there's one simpler way I have to defeat this: While answering the question, set the system clock backwards in time. Negative duration! Beyond that, you're still performing the encryption on the client, which is still outside of your control - the user can still access that to pass whatever timestamps they want. The harder you protect it, the more it tempts a certain crowd. – Clockwork-Muse May 2 '14 at 1:36
  • Server wise you can detect any negative timestamps. You can only hope for strong code obfuscation on the client so that it's difficult to extract the private key. – ndrix May 2 '14 at 9:01
  • Yes, but that's the only thing you can do. If I can send a negative timestamp, I can send a (near) 0 duration one. Also, fun stuff - the user may not have control over the system clock, so it may get rolled backwards unintentionally (due to NTP). Now what? – Clockwork-Muse May 2 '14 at 11:14
  • Well, in all fairness: you can never 100% trust anything coming from a client. I think it's merely a "how much of effort do you want to do?" on both sides which will determine if it's "secure" or "broken". – ndrix May 4 '14 at 4:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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