I've been thinking of a way to protect my datafeed(json strings) from third party apps and websites using it.
so I came up with a way of protecting it but I'm kind of curious about how good my protection will be.
client side
int passcode, int dateint
passcode = 15987456 //random static code
dateint = 20112805 // todays date all stuck together
return (((Integer.parseint(passcode + "" + dateint) * 9)/2)*15)/3 // stick the 2 numbers together and do random math on it.
on the server side php
$passcode = 15987456 //random static code
$key = $_POST['key'];
$key = ((($key / 9) * 2) / 15) * 3; // reverse the random math
if(substr($key, 0, strlen($passcode)) === $passcode){
$dateyear = substr($key, strlen($passcode), 4);
$datemonth = substr($key, strlen($passcode)+4, 2);
$dateday = substr($key, strlen($passcode)+6, 2);
if(!($dateyear === date(Y) && $datemonth === date(m) && $datedate === date(d))){
die("access denied");
}
}
eventually the random static passcode could be fetched from another page and it could then be dynamic...
don't mind syntax/coding errors. just wrote this off the top of my head.
There are three immediate problems I see:
- I understand your code is just an example, but your random math isn't very random:
x*9/2*15/3 == x*22.5. If someone wants to break that they will. Using a real cryptographic algorithm like md5 or sha would be much more secure.
- Using today's date in the algorithm isn't very reliable: the client could be on the other side of the world where it's already tomorrow or still yesterday, or the client computer's clock might just be plain off.
- Finally, if the site that's authorized to use the data feed is a public site, anyone can just look at the JavaScript code and check what the protection algorithm is, making even the most (otherwise) secure algorithm useless.
Here's an example that demonstrates why the key is very easy to crack. If you run the algorithm with a couple of consecutive days you get:
20110905: 2235971776452495360
20110906: 2235971776452495388
20110907: 2235971776452495410
20110908: 2235971776452495428
20110909: 2235971776452495452
The difference between today and tomorrow is 28, between tomorrow and the day after 22, then 18, then 24... There's a clear pattern there and you don't need to observe the code for very long before you see it. The malicious party can just try a couple of numbers that match the pattern and hit the right one very soon.
One of the first rules of cryptography is to always use an existing standard. If you try to make your own then it will be weak. Either use the client's Public Key or Diffie Hellman to establish the key at the client's site.
If your application (which uses the feed) is on the attacker's computer, and thus runs under his control, there effectively is no way to have data that your application can read but the attacker can't.
You can make it a bit harder by encrypting the data, but then the encryption key is in the program. There are some ways to protect the key (this is known as white-box cryptography, have a look at the white-box tag on crypto.stackexchange.com for details). Still, the attacker can simply execute the part of your program that decrypts the data.
You really need some user-specific key here (either a secret key shared between you and the user, or a user's private key, where you use the corresponding public key to encrypt the data).
