[严重警告] 从现在开始不要看MDK的帖子，并安装弹出窗口杀除器....MDK居然利用论

以下引用Misha在2004-10-6 23:05:22的发言： ....楼上....真米神已经发威了..... >_< 还有，人家scegg的意思估计是，SessionID将不再起作用，Cookie里面装的是你本人的用户密码，每次操作都需要直接对比密码，这样你的猜SessionID大法就失灵了... LOL 但是，这样做会导致数据库的流量和操作次数大大增加..........我觉得不妥，最好的办法是，对Cookie进行全文加密，或者在cookie里面附加内容数字签名，这样cookie就不可改了。

我是负责写KFC2核心WebService的，并不负责站点建设。我的所有函数调用都需要提供账户和密码，至于密码如何存放，那是站点页面处理的问题了。

以下引用Misha在2004-10-7 13:26:40的发言： Cookie里面绑定IP地址，看你怎么办 -_-b

这个...可以实现是可以实现……
通过绑定IP的C段或者B段。
不过会有一个问题，就是代理的问题。

这么来就是当登陆IP段不符合条件时COOKIE无效，除非不用代理上网，而且不会经常变更上网的IP段（例如公司用的IP段是一个，家里IP段是一个……绑定中国段？哇，那和没邦定有区别么？ ＝0＝）
而且还会有一个问题，例如我在家里上网存了一个COOKIE，然后我去公司上网变了段，这样家里的COOKIE也会一起失效，因为绑定段变了。
……

总之这个问题是头痛但是不能很好解决的问题。
就像我们明明知道电脑辐射对人体伤害很大，却很难离开电脑生活一样……只能尽量避免了。

"这个问题是头痛但是不能很好解决的问题。"

这有什么难得，你再仔细想想.......需要绑定中国段？......-_-bbbb
人说: 搞建设和搞破坏是两个截然不同的思考方式.......果然........搞破坏这么拿手，建设性思维就不敢恭维了......




"例如我在家里上网存了一个COOKIE，然后我去公司上网变了段，这样家里的COOKIE也会一起失效，因为绑定段变了。"

每次正确输入帐户，就在加密的Cookie里面建立一个绑定，根本不需要在服务器端更改任何记录，所以你的旧绑定也不会失效......只需要在Login的地方附加一个CheckBox，指明是否需要绑定就行了。比如在网吧，就不要绑定IP，这样就不会生成可持续使用的cookie，Session也是会维持到浏览器关闭为止。由于整个cookie是全文加密或者是使用了SHash算法签名的，不会存在受到更改的威胁，所以理论上可以建立数个绑定，同时作用。

哈哈，这样Taishen的"多重登陆"的功能就可以被进一步发挥，合体ID的所有使用者都可以免去每次输入密码的麻烦了。

不一定。其实我只是按照我的“破坏”思维逆向考虑的……  － －

加密或者算法签名的目的是为了防止明文泄露，所以采用什么算法是另外回事，也和防止COOKIE伪造也毫无关系……除非不让客户端保存任何数据。

也就是说这个段的问题。
如果是拨号或者ADSL，还是要用至少C段的绑定。

按照你的说法……也就是将IP和COOKIE放在一起使用签名或者加密？
总之你必定有个一个机制来识别IP与COOKIE的关系，也就是某种加密算法了……
如果使用了不可逆算法，不在服务器端保存数据是不现实的。所以一定是加密算法，而且可逆，考虑到服务器处理能力，算法对服务器的负荷能力也需要考虑。
（貌似伪造就要看入侵者的算法破解能力了？）

－v－
我已经开始理解你说的COOKIE全文加密了，这么说来从一定程度上来防止伪造还真的要COOKIE的全文都加密，呵呵～～（看来这种算法还需要相当大的工作量来开发 － －|||）

用SSL如何?

以下引用zhangmdk在2004-10-8 1:03:16的发言： 不一定。其实我只是按照我的“破坏”思维逆向考虑的……  － － 加密或者算法签名的目的是为了防止明文泄露，所以采用什么算法是另外回事，也和防止COOKIE伪造也毫无关系……除非不让客户端保存任何数据。 也就是说这个段的问题。 如果是拨号或者ADSL，还是要用至少C段的绑定。 按照你的说法……也就是将IP和COOKIE放在一起使用签名或者加密？ 总之你必定有个一个机制来识别IP与COOKIE的关系，也就是某种加密算法了…… 如果使用了不可逆算法，不在服务器端保存数据是不现实的。所以一定是加密算法，而且可逆，考虑到服务器处理能力，算法对服务器的负荷能力也需要考虑。 （貌似伪造就要看入侵者的算法破解能力了？） －v－ 我已经开始理解你说的COOKIE全文加密了，这么说来从一定程度上来防止伪造还真的要COOKIE的全文都加密，呵呵～～（看来这种算法还需要相当大的工作量来开发 － －|||）

"加密或者算法签名的目的是为了防止明文泄露，所以采用什么算法是另外回事，也和防止COOKIE伪造也毫无关系……除非不让客户端保存任何数据。"

常见误解。加密算法是为了保证数据的安全，明文不被泄漏，正确；但是签名则是为了保证数据的完整性和数据源的合法性，两个不是一个概念。




"这么说来从一定程度上来防止伪造还真的要COOKIE的全文都加密"

不用...全文加密只是提供一种更好的保密性而已，使脚本使用的存取变量名都不可见，加大伪造的难度。事实上根本不需要使用全文加密就可以达到不可更改的效果。(参见以下对SHash的说明)




"如果使用了不可逆算法，不在服务器端保存数据是不现实的"

不正确。我提到了SHash算法，这种算法早就被应用到身份验证协议中了。所谓的SHash就是把一段需要签名的内容和一组密码一起通过Hash算法(MD5/SHA-1)获得指纹，这样得到得指纹同时具有两个部分的特征。更改其中的一个部分就会造成检验无法通过，但是要重新生成指纹，则必须得到另一部分，而这部分在服务器端，你是拿不到的。因此服务器端只需要一个预设定的密码，就可以处理所有的Cookie签名了，而且使用快速的不可逆算法，根本不会增加负担。



"（貌似伪造就要看入侵者的算法破解能力了？）"

正确，任何的数字内容都是算法产生的，当然必定有对应算法破解。曾经受美国联邦政府信赖的DES56bit算法现在已经有专门的硬件可以在数小时破解(一个体积巨大的PCI卡，而且一台机器可以插数个这样的卡 -o-)专业的机器则可以在数秒钟破解...虽然128bit密匙目前仍然很安全，但是不排除数年后被干掉的可能性。MD5 SHA-1经过验证都存在签名碰撞的问题。任何算法理论上都是不完美的，最终都只有靠物理的定律解决问题，这就涉及到量子物理，扯远了......茶......

以下引用scegg在2004-10-7 15:06:43的发言： 我是负责写KFC2核心WebService的，并不负责站点建设。我的所有函数调用都需要提供账户和密码，至于密码如何存放，那是站点页面处理的问题了。

这就是我要指出的问题啊.....既然每个函数都需要提供帐户和密码，就必然导致每次数据操作都需要产生一次用户数据库的读写......你想一想，每一篇帖子，包含用户名，头像，经验，金钱等，还有帖子内容，再加上可能的上传附件，可能的特殊代码(类似于payview, userview) 这样每显示一片帖子，就会多产生出几个数据库操作......这样我想效率是会出现问题的，因为数据库本身的日志文件会变得极其庞大.....

以下引用wdx04在2004-10-8 13:45:55的发言： 用SSL如何?

这里讨论的不是这个层面的问题.....

以下引用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：远了……远了………………茶

以下引用Misha在2004-10-8 14:36:37的发言： 这就是我要指出的问题啊.....既然每个函数都需要提供帐户和密码，就必然导致每次数据操作都需要产生一次用户数据库的读写......你想一想，每一篇帖子，包含用户名，头像，经验，金钱等，还有帖子内容，再加上可能的上传附件，可能的特殊代码(类似于payview, userview) 这样每显示一片帖子，就会多产生出几个数据库操作......这样我想效率是会出现问题的，因为数据库本身的日志文件会变得极其庞大.....

阁下并没有做过WEBSERVICE吧。
首先，WebService并不会对所有访问去操作数据库，而是信赖缓冲；数据库系统也不会对所有请求进行查询，而是信赖缓冲。
另外，程序开发是分层进行的。最核心的是进行数据读写的，这部分是不需要验证的，因为外界访问不到它们，它们是内部函数。而外围的事务逻辑层才是被外界访问的，它们把一个大任务拆成很多小任务，一次验证后分别处理，并返回结果。
还有，由于KFC本身使用了ACCESS数据库，并没有日志问题。

一般的，以目前的计算来看，KFC2的数据访问次数和数据读取流量都小于KFC的平均值，所以阁下不必为此担心。