前天，我发布在博客园上的某知名电商网站的Cookie漏洞引发园友们的热议，学到了很多知识，现在整理一下其中比较激烈的技术讨论。谁对谁错每个人自己心中都有一把称，很多时候都是我无法说服你，你也无法说服我。
论题1：
网友：https是安全的，在传输过程对cookie等数据进行了有效的加密，所以https站下的Cookie也是安全的；
我：https下的cookie在传输过是安全的，但在客户端上是不安全的，使用客户端的有用户还有黑客；
我的论据：假设在某网站A下，我登录了自己的账号，打开浏览器cookie时发现有一条是这样 user = batsing ，然后我会想我把 user 这个cookie的值改成了别人的用户名是不是直接就可以登录了别人的账号呢？如果服务端程序是直接根据这个cookie值就认为是这个用户的话，那么这样的做法是很可行的。
我的建议：无论有没有使用SSL，Cookie值都一定要经过高强度难破解的加密算法进行处理。
论题2：
网友：哈希算法用在加密领域是可以信赖的
我：哈希算法用在加密领域是不可信赖的
我的论据：1、哈希算法产生的密文具有明显的特征，为黑客破解指明的方向。哈希算法产生的密文全为数字加纯小写字母（或纯大写），MD5为32位，SHA1为40位，SHA-256为64位，SHA-512为128位。2、哈希算法已经有大量的彩虹表和数据库作为破解工具，破解难度大大减少，其安全性值得质疑。
我的建议：所有的密文都要使用没有明显特征，不易被破解的算法进行加密处理，推荐使用AES加密算法。PS：我以前不知道有AES算法的时候，是混合使用了SHA1、字符串截取和Base64处理的，弄成一眼看上去也不好破解的样子（同时包含数字、大小写还可能有符号←_←）。
总结：
1、Cookie是可以安全使用的；
2、现在几乎每个月都会有几起安全问题被曝光，我们程序员更要提高安全意识；
相关安全议题：
一、注册/登录表单的密码安全
方案1、使用SSL，使表单信息在传输过程中为密文状态，被截获时仍然难以破解利用；
方案2、使用安全控件，比如银行的网页和一些大型电商的网页，在客户端加密了再传输；
方案3、使用JS加密密码，到服务端再解密，但由于JS是可见的，加密算法也是可见的，所以JS文件本身也需要进行加密压缩让其难以阅读；
二、字符串加密
方案1、很多网站在用的多重哈希加密；（不推荐）
方案2、AES加密；
方案3、现有加密函数加上自己编的一些字符处理方法组合；
三、Cookie记录用户应包含和验证的原始信息
1、用户名√ 用于识别用户身份的标识
2、浏览器信息√ 用于阻止部分黑客电脑浏览器直接窃用手机Cookie
3、IP地址ㄨ PC可以用但手机不能用，手机IP经常会变
4、时间戳 ？ 用途要看具体算法。如果Cookie密文无法还原出原文的时间戳那么就无法校验时间戳的有效性；如果可以还原，那么此cookie就可以在后台判定在规定时间内有效（注意这里的有效期与平时说的cookie有效期不一样，平时说的有效期是过期会被浏览器清走，而这里的是被窃走的cookie在超过一定时间后就不被后台程序认同）
5、有没有办法获取和使用更独立的信息，***是与设备绑定的。比如MAC地址，比如手机的序列码。
6、cookie一般网站可以使用，提高用户方便性。但因其有较大被窃取的风险，所以与金钱直接相关的网站/页面建议不使用cookie。
如何让别人把cookie复制走了也无法登录，这个还没有想到比较好的解决方案，求指教。
