Is my method of ensuring the integrity of a string secure?

This is my first question here so let me know if I'm doing things wrong!

I am building an Android application with Eclipse and am reading QR codes with the barcode reader. This is all working just fine, however, sometimes there are 'special case' barcodes that contain a 'reward' for the user.

This 'reward' is contained in a specially formatted string, this string COULD be tampered with by people who intend to cheat the system. This isn't a huge issue but I have implimented steps to prevent it, now my question is... How secure are these steps?

Here are two examples of the strings:

***Code-v1.0:31c8f90a4050:1001:0:C:1337
***Code-v1.0:6a9c4e8d92da:1002:C4D23A1B:C:1337

The strings are formatted like so:

***Code-v1.0:HASH:CODE_ID:REDEEM_ONCE:CODE_ACTION:ARG
(REDEEM_ONCE has 3 possible values)

My hashing system work like so:

salt = "************:***"; // didnt think it wise to post this, but the length is
                           //  the same and its开发者_开发知识库 alphanumeric
MD5 = salt . ":" . codeParts[2] . codeParts[5] . codeParts[4] . ":" . codeParts[3] . ":";
MD5 .= codeParts[4] . codeParts[3] . ":" . codeParts[5] . codeParts[2];

Is this a secure way of doing this, the code cannot seem to be tampered without affecting the hash, but surely hashes can colide and if somebody worked out the hashing scheme it all becomes pointless (this is a little less of a risk of just 'finding' it as it's on the server side, but if somebody figures it out).

What are your thoughts?

If you sent the parts and the hash, but NOT the salt anywhere (Just to be sure ;) ), you look like you are on the right track. Some remarks:

1. why are you using md5? The SHA-family is more secure.
2. Our payment provider recently went to formatting the strings like this, to ensure longer strings where collisions (their reasoning) are less probable:

codepart1.SALT.codepart2.SALT.codepart3.SALT etc.

Technically it wouldn't be a salt i think, but still..

So send your hash and your codeparts, and recreate the hash from the codeparts and salt/secretstring and you're set.

I see one problem: Your secretstring has to be really secret, and it's in your application. So reverse engineering could show how your hash is made, and so they can alter the fields AND the hash you are sending?