以下引用Misha在2004-10-8 14:29:19的发言：
恕删...... |
不用...全文加密只是提供一种更好的保密性而已，使脚本使用的存取变量名都不可见，加大伪造的难度。事实上根本不需要使用全文加密就可以达到不可更改的效果。(参见以下对SHash的说明)
"如果使用了不可逆算法，不在服务器端保存数据是不现实的"
不正确。我提到了SHash算法，这种算法早就被应用到身份验证协议中了。所谓的SHash就是把一段需要签名的内容和一组密码一起通过Hash算法(MD5/SHA-1)获得指纹，这样得到得指纹同时具有两个部分的特征。更改其中的一个部分就会造成检验无法通过，但是要重新生成指纹，则必须得到另一部分，而这部分在服务器端，你是拿不到的。因此服务器端只需要一个预设定的密码，就可以处理所有的Cookie签名了，而且使用快速的不可逆算法，根本不会增加负担。
这个……好像扯远了一些…… ＝ ＝
不，是越扯越远了，你提到SHARH算法保留KEY的时候我才反应过来，怎么开始讨论算法安全性了？
明明开始是讨论COOKIE伪造的可能性来着 － －
恩，来看看通常的伪造方式吧。（还是破坏性思维啊 XD）
大概分为两个部分：1、暴力破解 2、算法破解 3、投机取巧
1、强行碰撞HASH算法，无视所有的KEY以及其他内容…………（爆，这基本上是不可能的，玩MU的例外
2、算法破解，已知你的HASH算法以及KEY，这样的话自己生成自己需要的指纹。（－O－，说实话我讨厌这类看得莫名其妙的术语
3、投机取巧……
啊，这个才是真正用的最多的啦～
看看COOKIE数据与数据库内数据的分类与验证方式：（算法以及安全性放一边先）
COOKIE明/数据库明 －》 直接验证/签名验证
COOKIE密/数据库明 －》 COOKIE逆运算后对照/数据库运算后对照
COOKIE明/数据库密 －》 COOKIE运算后对照/数据库逆运算后对照/COOKIE运算后与数据库二次运算后算法逻辑对照（这人是BT）
COOKIE密/数据库密 －》 直接验证/双方逆运算对照/双方二次运算对照（也是BT）
可以看出现在大部分使用的是第四类的前面那种验证方式。
就是COOKIE加密内容直接和数据库加密内容对照。（KFC现在就是这种形式。）
投机取巧的伪造方式就是直接得到你的密文，然后伪造。
我完全不用管SHASH算法的KEY内容，以及算法的指纹结果是否正确。
因为我得到的就是数据库内存储的数据（例如SQL注入后得到的PASSWORD、USERNAME等，也许经过了MD5加密，但是我完全不用去管）
我需要知道的是你的密文，而不是算法也不是KEY。
因为提交对照的只是内容。
（也就是说，排除了我在两手空空情况下来强制伪造的情况，这种情况也是很少的，除非特殊目的）
例如这次我伪造你的ID，我只需要通过某种方式得到你的SESSION ID，SESSION PASS，USER ID，MD5签名后的PASSWORD。
然后就可以伪造成功。而关于MD5签名的算法，SESSION PASS的随机算法，和我无关……
解决方法其实也有一些：
就如你说的签名内容中加入IP段，这样伪造的话就难了。
还有一个方法就是采用随机KEY的形式，数据库中加入一个KEY表，对应每个人的COOKIE使用的随机KEY。
不过，这样的话就只能使用一个COOKIE了，解决方法是追加一个多个COOKIE列，用COOKIE中的某个数据（例如0-9）来保证COOKIE列的对应，以读取到正确对应的KEY。（不过这样会增大一些数据库就是了 － －）
PS：远了……远了………………茶