这是保护数据源的明智方法吗?
我一直在考虑一种方法来保护我的数据源(json 字符串)免受第三方应用程序和网站使用它的影响。
所以我想出了一种保护它的方法,但我有点好奇我的保护效果有多好。
客户端
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.
服务器端 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");
}
}
最终可以从另一个页面获取随机静态密码,然后它可以是动态的......
不要介意语法/编码错误。只是在我的脑海里写下了这个。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
密码学的首要规则之一是始终使用现有标准。如果您尝试自己制作,那么它会很弱。使用客户的公钥或 Diffie Hellman 在客户站点建立密钥。
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.
如果您的应用程序(使用提要)位于攻击者的计算机上,因此在攻击者的控制下运行,则实际上无法获得您的应用程序可以读取但攻击者无法读取的数据。
您可以通过加密数据来使其变得更加困难,但加密密钥位于程序中。有一些方法可以保护密钥(这称为白盒加密,请查看白盒有关详细信息,请访问 crypto.stackexchange.com 标签)。尽管如此,攻击者仍然可以简单地执行程序中解密数据的部分。
这里您确实需要一些特定于用户的密钥(您和用户之间共享的密钥,或者用户的私钥,您使用相应的公钥来加密数据)。
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).
我看到三个直接问题:
x*9/2*15/3 == x*22.5
。如果有人想打破这一点,他们就会这么做。使用真正的加密算法(例如 md5 或 sha)会更安全。这是一个示例,说明了为什么密钥很容易被破解。如果您连续几天运行该算法,您会得到:
今天和明天之间的差异是 28,明天和后天之间是 22,然后是 18,然后是 24...那里有一个清晰的模式,您不需要在看到代码之前观察它很长时间。恶意方只需尝试几个与模式匹配的数字即可很快找到正确的数字。
There are three immediate problems I see:
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.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:
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.