views:

89

answers:

2

I want to prevent users tampering with the the data generated in my iPhone app, such as high scores. So I'm thinking of using an MD5 hash of the relevant data, and a security salt hard coded into the app. When the data is read back in, I create a new hash and compare it to the old hash. If there's a difference, I know someone has been fiddling with the data.

I'm guessing there's always going to be a way for people to get round it, but will this method make it;

  • Very difficult.
  • Tricky to work around.
  • Makes no difference at all.
+2  A: 

I'd say tricky, but not very difficult. It's still fairly straightforward to step through with a debugger and watch the salt getting loaded into memory, though it's certainly enough to keep out the vast majority of users.

Unfortunately, this is the classic DRM problem, and has no solution against a sufficiently motivated attacker. Your best bet is to create as many barriers as possible, such that it isn't worth someone's time.

Perhaps the submitted high score could also include some details on game state, which would allow you to check for inconsistencies that might give a user away. For instance, if you see that a user achieved 1,000,000 points but only reached level 2 then you know something's up!

A quick win that will at least defeat a user running strings against your binary is to make sure the salt string doesn't look obvious; don't use "saltsaltsalt"!

jnic
MD5 has a length that is to short and really should not be used in new designs, SHA-1 or one or it's newer cousins such as SHA-256 should be used.
zaph
In this case, the problem isn't collisions but the hiding of the salt itself.It's significantly easier for a user to extract the salt with a debugger than to compute collisions (or attempt to extract the salt by brute force) so this is not a viable attack vector.
jnic
SHA-1 does not have a salt, none is needed so there is not issue with a hacker finding the salt. Salts are used with MD5 because the result is to short.
zaph
But someone could still easily rebuild the hash using SHA-1? So a salt is still needed.
gargantaun
A: 

Assuming that the user can't replace the old hash the concept is fine. But use SHA-1 instead of MD5, it is much more secure and becuase of the increased length (160 bits) there is no salt.

zaph
Salts are a not a property of the MD5 hash function, they are function-agnostic, as their purpose is to confound known-plaintext attacks (among others). Thus, using (for instance) SHA-1 instead would confer no advantage in this case.
jnic