没看明白。。。你这个 post 请求不是 https 的么？

客户端最多做个对称加密好了，有啥意义呢，既然 https 了没啥可说的吧
不要被代理劫持就行了

你是对的，我刚忘了是 https

445 位会员

嗯嗯，不是问题

就算是 http 直接加密也没什么意义

是么？为嘛，没做安全。

你想想，http 下：

• 如果是用 hash，MD5 串往后台传，后台数据库不可能让你保存明文吧，也是 MD5 串，这是什么概念
• 直接在浏览器做个 AES 或者 DES 这种对称加密或者自定义的对称加密算法，不对称咋弄，到后台你自己也识别不了啊，但是对称加密存在的意义是啥，我感觉就是费别人点功夫而已，就算你 JS 混淆了，别人还是有办法解析出来
• 总结起来，要么 https，要么索性不用费劲……不然怎么的别人总归还是会有机会跨站或者代理劫持的~

谢谢。 学习了。 我以前观点是 http 下得加密，还得做混淆。 原因是技术毕竟有梯度，多做一层多挡住一层次用户。

早期注册而已。。。 再来术业有专攻嘛。。。安全这块目前我确实还是小白。

由于现在用户密码一般都是用 Cookie 保存在客户端上，因此就整个系统而言，其不安全的地方有 2 处：1、Cookie 可能会被暴力破解；2、通讯可能会被监听。

对于第 1 点来说，由于 Cookie 是一个明文的键值对，所以一般加密我们需要对这个 Cookie 的 Key 和 Value 进行加密，Key 我们可以直接使用 MD5 进行加密（确切得来说 MD5 不算加密，一切不可逆的都不能算加密，只能算摘要），而 Value 我们一般是用可逆的加密方法进行加密，其中可逆的加密方法分为对称和非对称，对称加密的加密强度虽弱于非对称加密，但其性能优于非对称加密，所以一般都使用对称加密来对 Value 的值进行加密。

对于第 2 点来说，就是在 TCP 和 HTTP 之间加入一个 SSL/TLS 协议，使 HTTP 变成 HTTPS，从而防止攻击者的监听

以上就是我目前的理解

我们公司任何情况下不允许明文传输或保存密码

密码加密 是为了防止运营人员做鬼

是否存在一种加密算法：加密后上传的文件，服务器无法查阅内容，但是可以帮你找回密码？ - 玄星的回答 - 知乎

前端加密防止不了中间人攻击，但可以用来防止内部人员窃密、保护用户隐私、在服务端日志和内存中不出现明文。

嗯，是的，学习了
对于内部审计缺失的公司来说，怎么防内部作弊也是个蛋疼的事情

密文密码也不可以保存么？

是的，如果发现在手机里面存储数据的话，密码也不允许明文存储

其实一般用户的账号密码这些都是保存在 Cookie 里。

从攻击者的角度（在没有 SSL/TLS 协议的情况下），攻击者可以监听你的用户，获取其 Cookie，当攻击者获取到 Cookie 后，他可以直接用这个获取到的 Cookie，登录你的用户的账号，为此我们需要在前后端通讯时，对相关数据进行加密，这样攻击者即使监听了你的用户，其获取到的 Cookie 也是经过加密后的 Cookie，用这个 Cookie 进行登录你的用户的账号，其加密过的 Cookie 会再次二次加密，最终导致服务端在解密后获得的 Cookie 是一次加密的 Cookie，这样子服务端所获得的 Cookie 的数据当然就不对了，这也就防止了攻击者去监听你的用户，当然 HTTPS 只是在 TCP 和 HTTP 之间加了 SSL/TLS 协议，其只保证数据在应用层到传输层的数据是安全的，但是在应用层内，相关数据还是未加密状态的，也正是如此，像支付宝这些和钱有关的公司，都会有一种叫做安全控件的东西，其其中的一个作用就是保证相关数据在应用层内也是经过加密的。

上面说的就基本保证了攻击者无法通过获取到的 Cookie 去直接登录用户账号。

从攻击者的角度，既然无法用过获取到的 Cookie 去登录你的用户账号，那么攻击者可以直接暴力破解这个 Cookie 并获取到真正的账号和密码，为此我们就要对这个 Cookie 的本身进行相关加密，一般我们都会对 Cookie 的 Key 和 Value 进行加密。

以上就是我目前所知的有关 Cookie 的加密策略。

当然加密是影响性能的，同时由于加密也会衍生出一个秘钥管理的问题，所以具体要怎么加密，要不要加密，这些问题都是需要权衡的。

最后我想吐槽，这标题错了吧，应该是 在 HTTPS 协议下，是否需要对相关数据进行加密 吧！

前段时间刚看了网易公开课里华南理工的计算机网络安全，5 个课时，还是比较容易理解的，有兴趣的同学可以去看看。

怎么突然就再次二次加密了？ 我不太理解