@strwei md6 是 hash 啊，不是加密算法吧，你文本变成 hash 后，就没办法恢复过来了吧。

C++百搭小王子，基本上啥都能干。就是调试和内存泄漏要求很好、工程大了 bug 不好定位。

Js 用对称加密就是掩耳盗铃、你们要学会用非对称公式加密解密。

我们的服务器死后、拒绝任何 ip 包的数据、远程都没办法、只有给机房打电话。

可以的吧、直接把 b 指向 a 的域名、 a 服务器设置一下 host 、允许 b 站访问即可。

其实可以在 b 站的服务器设置端口转发、不用设置 a 站任何东西、一样的效果。

完全代码就是
int main() {
int a = a + 3;
return 0;
}

调试运行，某些 vc 版本 a 的值会乱，某些 vc 版本会 crash ，行为并不一样。

我就不知道，为啥楼上不能把 HTTPS 里表单 POST 的用户名和密码，理解成普通的数据。而一定要做特殊处理。

好，就算特殊处理，很多论坛的数据库里，存密码是加密形式，用的是 blowfish, 还是很容易被解密成明文。

假设，如果 GOOGLE 浏览器完全用 JS 重写底层， SSL 相关代码全部改成 JS 端，很容易下断点，估计现在的 HTTP AES 各种加密模式会发生翻天覆地的变化，在未来，没人会在乎世界上曾经有一个算法叫 AES 。非对称算法将会遍地开花，普照人间。

如果只是防止第三方非法修改数据内容，个人觉得数据发送前做个全局数据流 hash, 然后签名就可以了。

签名不能伪造 => hash 值无法被第三方修改 => 数据流安全。

主页是百度、优点是打开速度快、毕竟谷歌是要爬墙的。然后每次搜技术、什么都木有、都要逼切谷歌～_～

楼上的观点不能赞同，这里 POST 里的用户名和密码，别和 SSL 里交换密钥的概念搞混了。表单就是一个普通数据而已，你如果换成 https 里的 post 提交，最终 HTML 表单里，用户名和密码加密还是走的 AES 加密通道。

更甚者，你要是能通过 HOOK 浏览器，从内存顺利截取到 AES 的 KEY 密码，就算你用 SSL 安全传输，还是照样能够还原原文，这和密钥交换一点关系都没有。这就是我说的不安全终极原因所在，任何人都知道的公开算法，给一个 KEY 就能还原，被破解。

能不被破解的，只有自定义的单向加密算法，比如 NURSB 三维空间加密，听这名字就知道高大上，只要把 JS 客户端投影公式做个化简，神仙也还原不了服务器反投影公式。就如上面说的，求代数函数反函数难，求几何投影反投影更难。 ECC 知道不？就是基于几何原理，还只是二维的，不是三维的。

强有力的技术 leader 、会强制重构的、可惜 dz 没有。

原本前端没那么明显、直到谷歌把 ajax 引人 js 开发、让页面直接处理交互性数据、逻辑越来越复杂、就独立出前端这个职位了吧。

黑客并不知道用户的密码位数是多少，假设盲目暴力猜测，一位一位的穷举尝试， 93 + 93^93 + 93^93^93 ... 一直尝试到第九位攻击结束，近 5260677251 亿次密码攻击是完全无效的，然后才开始有效攻击。

<img src="http://dn-cnode.qbox.me/FgDUQB1Uo00fgejQD3OazqQeDng3">

这图中最后的 mac, 才是摘要算法。而不是所谓• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 里的 SHA256 。

哈，我就是用野狗主页做 CHACHA20_POLY1305 算法测试的。。因为在 V2EX 的 ssl 区域经常看到贵站。

可是加密协议只有老版本的 OLD_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCC13), 没有新版本的 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), 后者可是修复了前者的各种问题，作为标准来替代前者的。

每次测试 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 时，连接 https://www.wilddog.com 总是返回握手失败，不爽！


--------- 最后喷一下 ---------
"RSA 做身份认证、 AES256-GCM 做加密算法、 SHA384 做摘要。"
这句说法不对，在以前的版本里 AES256-CBC-SHA256, 最后 SHA256 确实是指验证加密有没有错误的摘要。但 AES256-GCM 不一样，是新版 HMAC 和加密的合成体产物，不仅仅承担的加密责任，同时也整合了固定 16 字节的校验值，并不是 SHA384 的 384 位校验值。所有新版 AEAD 的加密算法，都自带校验功能。

这里 SHA384 不是摘要，是握手时的协议规范而已。

"那在什么时候算 ECC 呢？用户设定密码的时候？", 第一次写数据库前，把明文密码做 ECC 处理，生成 ECC 多项式字段保存在数据库里，然后把明文密码变成哈希密码，存到数据库密码字段里。

ECC 神奇的地方，是修复后，只需要凭借修复字段和模糊错误密码，就能猜出原正确密码，计算出密码 hash 。

举个例子，你 winrar 加入的压缩修复功能后，数据有部分损坏也能自我修复，并不需要保存一个原数据副本的，你只要有原文的哈希值作为对比就可以了。和不用保存明文密码一个意思。

---------------
"我改密码就只改第一个字符，这样岂不是旧密码还能登录"
模糊登录本来就是干这个的，哈哈。

我倒是觉得 AES 才不安全，太热门了，算法都被用烂了。如果用在 JS 里，你 100%要生成密钥，不管是什么密钥交换算法，最后总要传输到 AES_SETKEY 这个函数入口，黑客只要无脑在入口函数下断点，蹲点就可以了-_-

至于你说专业人士能不能逆推算法，我只想说对于普通人来说，逆推一个 y=sin(x)+cos(x)的反函数都很难，何况是自定义那种很复杂的多项式呢，并不是人人都是数学大神，对吧。

越冷门的算法，研究人越少，就越安全。

数据库里存的是密码 hash ，但每次用户登录是， POST 提交用户密码的时候，需要明文传输，不过也是安全的。

具体请见另一篇文章： Nurbs 三维曲面传输明文密码，保证不被中间人窃听。就是把密码当作平面 X,Y 坐标，投影到三维空间后变成 X,Y,Z 加密传输，服务器端拿到三维坐标，再投影到平面还原密码。中间人没有 nurbs 公式，没办法还原密码。

可以不用明文的， MD5(ECC(v3expassword)) = MD5(v2expassword)

计算好 ECC 后，就完全不需要密码明文了。就算数据库被盗，只靠 ECC 字段的多项式数据，也没办法还原密码，数据量太少了。