Web前端密码加密是否有意义？

https://www.zhihu.com/question/25539382

Web前端密码加密是否有意义？
既然前端代码都是直接可以看到的，那加密是否还有意义？
我总结一下，首先大家都知道走 HTTPS 才是目前唯一负责的方式。
但在 HTTP 环境下，无论如何都可能会被劫持流量，不管前端做不做加密都会被轻易成功登录。这个时候保护密码明文是否有意义？有人站队前端加密无意义，考虑的是这个加密对本站的安全性没有任何提升；但如果你是从保护用户的角度出发，用户多站点共享密码是现状，你在没法改变这一点的情况下，如果能够保护密码明文，至少降低了一点该用户其他网站（即使是 HTTPS 的网站）被一锅端的风险。这怎么能说完全没有意义？
有人说 HTTP 流量可以直接注入脚本，直接拿到用户输入的密码，这没错。但是注入脚本就是代价，只要能够提高一点点门槛就不能说没有意义，很多时候是这些收益和成本之间的权衡。
另外，赞同 @Rix Tox
，即使在 HTTPS 环境下，使用前端加密也并非没有意义，甚至对于保护用户隐私而言有很大价值。

很多回答分析得都挺对，但最后得出的结论我不能认同。0 就是 0，0.1 就是 0.1。

补充一下，关于
@eldereal的回答，他实际在论证的论点其实并不是「密码在前端加密完全没有意义」，而是「前端加密不能改善当前网站本身的安全性，不能因此降低后端的安全等级」。他自己的回答里都清清楚楚写了「这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上」，不知道为何还要强行缩小问题的范围，得出「完全没有意义」的结论。也许「保护自己网站的用户密码明文免受社会学攻击」对于某些人来说是完全没意义的？
有几个答案有很大的问题，为防止有人受到误导，我觉得有必要说一下：
密码在前端加密完全没有意义，对密码系统的安全性不会有任何提高，反而会引发不必要的麻烦。
首先，做前端开发的人需要知道，前端系统的控制权是完全在用户手里的，也就是说，前端做什么事情，用户有完全的控制权。
假设如同 @陈轩所说，前端做过了md5，后台就不用做了，这个做法会有什么后果？如果某一天，这个系统的数据库泄露了，黑客就直接拿到了每个用户的密码md5值，但此时，由于黑客知道密码是在前端进行哈希的，所以他不需要爆破出该md5对应的原文是什么，而是直接修改客户端向服务器发出的请求，把密码字段换成数据库中MD5就可以了，由于与数据库中记录一致，直接就会登录成功。这跟直接存储明文密码没有任何区别！！！所以不管前端是不是加密了密码，后台使用安全的哈希算法对内容再次转换是非常有必要的。（MD5可不行，要用bcrypt，我之前回答过一个类似的：随着显卡性能的高速发展，目前的快速Hash算法是否已经变得不够安全了？）
这个回答还有一个人赞同，希望大家别被错误答案误导了。
另外一个答案
@林鸿所说，在非安全HTTP连接上，可以防止原始密码被窃听。但问题在于由于你的登录系统接受的哈希过的密码，而不是原文，窃听者根本不需要原始密码，只要通过哈希结果就可以伪造请求登录系统。这样做只能防止被窃听到原文的密码被攻击者用在社会学攻击上，而不能改善该网站的安全性。所以不管前端是不是加密了密码，使用HTTPS安全连接进行登录都是非常有必要的。
以上我说的两点，合起来看就是：不管前端是否加密了密码，都不能以此为假设，让后端设计的安全等级下降，否则就会有严重的安全问题。实际上，前端进行密码加密，可以看做帮助用户多进行了一次原文的转换，不管用了什么加密算法，算出来的结果都是密码原文，你该如何保护用户的原始密码，就该如何保护此处的加密结果，因为对你的登录系统来说，它们都是密码原文。
以上这些，说明了密码加密是没有什么意义的，接下来，我要说明前端加密会带来什么问题。
1. 有些人会认为前端进行了加密，可以降低后台的安全性需求，这种错误的观念会造成系统的安全漏洞。实际上，你不能对前端做任何的假设，所有跟安全相关的技术，都必须应用在后台上。
2. 前端进行加密会造成页面需要js脚本才能运行，那么假设你的系统需要兼容不能运行js的客户端，就必须再设计一个使用原文的登录接口。
3. 由于前端是不是加密，所有安全机制都必须照常应用，所以为系统增加这样的复杂性是完全没必要的，即使传输明文密码，只要正确使用了HTTPS连接和服务器端安全的哈希算法，密码系统都可以是很安全的。
举的用例也是对的，就是所谓的端对端加密，服务器只存加密后的数据，也帮助公司规避政府要求解密用户数据的风险。Dropbox 是端对端加密，但是他们有你的密钥……
所有說重放攻擊的、中間人、劫持等等的都是不認真看答案的。密碼學跟網絡安全還是差得很遠的兩個專業，密碼學的很多應用場景其實跟網絡安全並無太大關係。
我就針對 「密码在前端加密完全没有意义」的觀點舉一個反例。
前端加密的意義不是為了防止中間人，而是提供一種隱私保護服務。
考慮下面的應用場景：
Client 想要在 Server 上安全存儲一份數據 M，使用密鑰 K，那麼我們可以採用這樣的流程：
1. Client 在前端對數據 M 進行 AES 加密： C = Encrypt(M, K) 2. Client 計算出密鑰 K 的 Hash： H = bcrypt(K) 3. Client 計算出數據 M 的 Hash 保存作為文件標識： ID = sha1(M) 3. Client 將 (C, H, ID) 發送給 Server，Server 進行儲存
當 Client 想要從 Server 上提取數據可以採用這樣的流程：
1. Client 計算出密鑰 K 的 Hash： H = bcrypt(K) 2. Client 將 (ID, H) 發送給 Server，Server 匹配驗證 ID 和 H 值后把對應的 C 密文發給 Client 3. Client 在前端對密文 C 進行 AES 解密： M’ = Decrypt(C, K) 4. Client 計算出數據 M’ 的 Hash 與 ID 進行驗證： ID =?= sha1(M’) 如果一致則表示獲取到的文件與原始文件一致 M == M’
在這組流程中，我們可以看到，Server 拿到的的信息只有 (C, H, ID)，從而能夠保證就算 Server 上的信息洩露也不會涉及到任何明文。
上述的流程有很多國外的網盤都在用，比如 Dropbox、Mega、PutDrive 等等，當然他們是在 HTTPS 通道上使用的，採用前端加密的目的也不是為了防止中間人，而是一種隱私保護服務。

===============================
@黎博 @王超 @fox fun 你們也許知道點網絡安全，但是涉及到密碼學卻是不一樣的。不是逆向不逆向得了的問題，密碼學算法基本都是公開的。也不是C/S; B/S什麼架構的問題，題目並沒有限制這個方面。
W3C雖然制定了前端加密的接口標準，但是並不限制應用場景。你們僅僅從自己涉及到的業務說這東西沒用是片面的。
密碼學的應用相當廣泛，「前端加密」不是單單只做個MD5 Hash這麼簡單的東西，你們覺得沒用那是因爲你們還沒遇到要用到的場景。在我看來國內的公司基本上都用不到「前端加密」，所以對國內行業來說，「前端加密」沒用是可以接受的。
但是放在很多國外的服務來說，「前端加密」的應用比比皆是。舉些例子：
Mega.nz、Dropbox 這些網盤服務提供端對端加密，也就是說你上傳的數據就連服務端都無法查看明文。這時候你不用「前端加密」要怎麼實現？
再來看看這個端對端加密的Markdown編輯器：standard notes app, un-standard every other way. 你告訴我不用「前端加密」怎麼實現？
再看看玄星回答的這個問題「是否存在一种加密算法：加密后上传的文件，服务器无法查阅内容，但是可以帮你找回密码？ - 玄星的回答 - 知乎」你們仔細思考一下不靠「前端加密」怎麼實現？
更不用說還有人打算把區塊鏈、智能合約在前端上實現了，類似的應用太多了，怎麼能說沒有意義呢？
请各位批判本答案的时候不要从 HTTPS 入手。
我们都强烈建议所有站都使用 HTTPS，在这里仅讨论前端加密的好处。
在我看来 HTTPS 与前端加密并不矛盾。
本文所述的前端加密指的是所有阻挡明文暴露的方法，包括散列。
@Rix Tox
讲的端到端加密不包含于本答案的讨论之中，因为那是必须的。。。而且答主非密码学专业，网络安全与密码学关系绝对是不大的= =
@顾轶灵
的答案与本答案相似，即：
前端加密不是决定性的保护措施，但却是一种有意义的低成本安全增强方案。
谢谢各位从密码学讲了这么多，作为一个信息安全专业学生（仅仅是初学了密码），答主并不打算从密码学上来说前端加密有啥用。因为在我看来，前端加密在算法透明的情况下，本身就仅仅是一种用户隐私保护方案，避免明文暴露罢了。
各位请记住，如果东西已经丢了，那么丢了密文总比丢了明文强。
这个思路同样应用于散点认证，其基础是增加攻击成本，尽可能降低攻击带来的损失。

正方：认为前端密码加密有意义
在某些场景下是有意义的。
我们的产品是一款比特币钱包：https://wallet.btc.com
用户在登录时输入的密码，同时会被用来解密私钥。私钥用于对交易进行签名。
在启用 HTTPS、前端没有加密的情况下，用户明文提交密码后，我们的开发人员可以通过日志、修改线上代码等方式获取用户的密码，从而产生用户财产安全隐患。
为了解决这个问题，我们需要用户在注册登录时使用盐对原密码做数万次哈希运算，将其做为密码提交给服务端，返回加密后的私钥。用户在发送比特币时，需要在客户端（Web、iOS、Android）输入密码，在客户端做计算得到解密后的私钥，之后再进行比特币交易签名。
观点
前端加密有意义并且有必要，至于为什么很多人不做，其实是一种成本性能权衡。前端的加密手段非常多，楼下只是选了俩种最基础的加密来说明自己的观点，而这俩种加密恰好有作者说明的这些问题。需要说明的是前端加密需要后端的配合，任何一种前端加密都需要后端配合。除了答主说的哈希算法和加盐之外，还有一些非对称的加密算法，使用公钥和私钥，动态口令计算，验证码混合校验等等，都能更好的保证用户的隐私和安全。
前端加密的唯一意义在于
如果你不是特殊目标，可以保护一下你的信息安全
打个比方，A买了一万个账号密码，其中某网站的账号密码是随机盐+hash，其他网站都是直接明文
虽然可以通过中间人+分析代码的方式获取到明文，但是很有可能因为这样太麻烦所以他选择跳过这个网站。

另外，不要因为前端加密了，后端就不加密，安全性是后端保障的，前端加密只是阻挡一些比较懒觉得不值得花时间分析代码的人。

最大的意义就是保护用户的隐私 – 明文密码
就算服务商的通讯被劫持（非 HTTPS 或证书泄露）、数据被拖库（出现安全漏洞）、内部员工查询，用户的明文密码也不会被泄露
对用户是一种负责的态度。
哪些说「密码在前端加密完全没有意义」的同学 Too young Too simple。
如果觉得「保护用户隐私没有意义」不是懒就是坏。
我会告诉你：登录之前密码自己做 hash 吗。相信别人，不如相信自己。

有意义，而且很有必要。当然我这里针对的不仅仅是密码，比如用户私钥等其他任何敏感信息。
你没有遇到类似需要前端加密的场景，自然就觉得没有意义。
后端确实不能信任前端的任何输入，但是并不代表前端也就一定需要无条件的信任后端。
很典型的一个应用场景就是比特币的钱包网站，具体交易过程这里不再追溯，可以参考著名的比特币钱包Blockchain的设计机制。
很多人说大部分情况HTTPS就够了，不需要前端加密，这是一种无条件信任后端的思想，并不可取。诸君请看：
据说 Cloudflare 泄露用户 HTTPS session 长达数月，涉及 Uber，1password，1password。。1password。。
最近就遇到了这个问题，起初我也自己动摇过前端密码加密到底有没有意义，但最终还是决定，修复该bug，前端加密传输用户密码。主要原因如下：
1、明文传输，本身就不符合安全常识。
2、明文传输，在中间人攻击发生时，无门槛，直接获取明文密码进行登录
3、至于前面朋友提到的，直接md5发送，其实完全可以带上一个有效期token＋加密后的密文密码来保障，这样即使你直接抓到了加密的密文，直接replay，此时token也过期了，无法完成登录的。
所有的加密算法都是公开的！ 那我们是不是在做没有意义的事情？
加密是一个很好玩儿的概念能做很多事。 比如： 我有一个密码，我想让你知道我有，但是我不直接告诉你这个密码。 zéro knowledge

香霖堂的茶叶
提问:不想编程只想写小说但是一直扑街怎么办……
4 人赞同了该回答
还是有点意义的。密码作为密文传播至少不会对用户造成二次损害……丢了我们站的密码，结果也能去其他站用同样密码登陆什么的。

前端加密不是完全没有意义的，而是很有必要的。别的不说，如果你明文传输入用户名密码，那报文传输过程中的安全怎么保证？用户点了登录，还要通信过程中的路由器等网络设备服务器才能收到的，这个环节你完全没法掌控。那把用户的密码就这样明文发出去，安全吗？就好比你让邮差送一封信给你的朋友，这封信中写了你的银行卡密码，你朋友需要拿到你的银行卡密码才能去银行取钱。那问题来了，不加密，你怎么保证送信的那个人不会偷看你的这封信？

所以，有条件服务器要上https，然后密码要做前端加密。还有，前端要做密码加密，以防有些浏览器不能访问https

再来加一发，说前端加密完全无用的，请去研究下腾讯、网易、百度这些一线大站有没有做前端加密，然后再来回答这个问题！如果你认为这些一线厂商的工程师都是傻B，闲得蛋疼才做这个，那我也无话可说了。
你觉得无用，只是你站在自己的立场去看问题，有些比较复杂的场景你没有遇到而已

前端加密的意义
在 HTTP 协议下，数据是明文传输，传输过程中网络嗅探可直接获取其中的数据。 如用户的密码和信用卡相关的资料，一旦被中间人获取，会给用户带来极大的安全隐患。
另一方面，在非加密的传输过程中，攻击者可更改数据或插入恶意的代码等。HTTPS 的诞生就是为了解决中间人攻击的问题，但如今 HTTPS 的使用情况在国内并不乐观，基本是因为成本或者性能的考量。

Q
那么问题来了，
如果仍然使用 HTTP 协议，
怎么样一定程度保证用户的数据安全？
A
前端加密，
即在数据发送前，
将数据进行哈希或使用公钥加密。
如果数据被中间人获取，
拿到的则不再是明文。

设想在如今公共 WIFI 流行的今天，一旦某一个 AP 的流量被攻击者劫持，如果密码和用户名都是明文，那么攻击者将轻而易举的使用这些资料进行 Replay 登录。更糟糕的是很多用户在不同的网站使用相同的账号信息，用户的隐私荡然无存。
作为网站服务提供者，网站设计和开发人员应该为用户提供相对安全的服务，这是一种责任也是一种情怀。
另外，如果前端使用哈希算法，不仅可以帮助后端分担部分计算压力，还可以增加撞库成本。具体的讨论将在下文继续。
前端做加密是有意义的。就拿md5来讲。
1。传md5和传明文一样？绝对不一样啊。链路被监听的时候，攻击人直接就拿到明文密码了，有很多人都习惯用一个密码的。明文的话，相当于直接把用户n多个网站的密码爆了，拿到md5的话，只有自己的网站密码被爆。对用户的危害范围明显缩小了好么。多少次用户icloud艳照泄露，最后都不是苹果的锅。。是别的网站被脱了好么。

1. 有一种有效实践是发送用户密码+时间戳的md5值。这样可以有效避免被监听。当然还要做一点客户端和服务器端时间差计算的工作量。哪怕被监听。攻击人拿到的加密后密码也很快失效。在做一点单帐号单登录的措施，用户密码安全性还是可以得到很大的保证的。

再说说他说的前端加密的缺点。
第一点，有些人认为前端加密，可以降低后台的安全性需求，这种错误观念会造成系统漏洞。。我也是醉了，因为前端加密会导致水平低下的程序员后端不加密，容易产生漏洞，所以我们前端不能加密！这是什么逻辑。。就跟说“写字楼大门保安太克尽职守会导致每一个楼层保安松懈，所以我们不能要大门的保安！”
2.“前端加密需要js运行，那么为了兼容不能运行js的环境，你要设计一个使用原文的接口”。 天呐。。你要对接的前端环境是不能跑代码的么？机顶盒可以用C,C++，路由器都能用python，现在还有不能跑代码的设备？
3.“增加复杂度” 没有好么。。只要你不傻到自己去实现md5，去实现其他加密，不管对于前端还是后端，都只是加个函数名的事儿。。

前端 hash 的好处
前端加密可以： （1）避免明文密码在传输中被获取 （2）保证后端日志等不会记录明文密码（也可以防止内鬼盗窃） （3）保证后端内存中无用户明文密码，在 dump 等情况发生时不会出现泄露问题
我们再说一下成本问题： （1）前端加密在不影响后端性能的情况下满足对用户密码的保护 （2）前端执行一个散列运算对前端来说真心不是事，密码这么短，不会影响性能。 （3）与 HTTPS 的流程相比，在前端散列一下几乎不影响网站响应速度和用户体验
最后，我们来说一下误区：
（1）前端散列不意味着后端可以减少安全工作量，前端散列一般会采用较为“低功耗”的弱加密实现，而不会使用 RSA 等方法（有人使用短密钥的 RSA 依然是不安全的）。
（2）前端加密不可以防范中间人攻击，中间人依然可以实施重放攻击。
一部分正方人的观点

当然在谈安全。前端安全是Web安全的一部分，常见的安全问题会有XSS、CSRF、SQL注入等，然而这些已经在程师界得到了相当高的重视并且有了很成熟的解决方案。 所以我们今天只谈前端“加密”，一个部分人认为没有意义的工作。 有争议的事情总是那么因崔斯汀，接下来就让我们谈谈前端传输中的数据“加密” 。
前端传输的数据我们应该用什么算法加密，如何组织整个加密过程呢？
一般有几种做法：
JavaScript 加密后传输
浏览器插件内进行加密传输
Https 传输

在这里其实 HTTPS 是终极解决方案，所以文章对于仍在使用 HTTP 建站的小伙伴更有帮助。本文中将讨论第一种方法，也就是使用 JavaScript “加密”。使用双引号是因为这里面分为两种手段，一是使用数据摘要进行消息杂凑，二是使用非对称加密算法对明文进行加密。严格意义来说第一种手段并非加密，而是一种信息摘要的应用，为了阐述方便下文统统使用加密一词。在进行下文之前，需要简单的介绍几个概念：
哈希与加密

上图中我们可以明显看到哈希和加密是两个不同的东西，主要有两点不同：
• 哈希算法通常用于数据摘要，生成相同长度的文本。而加密算法生成的密文长度与明文长度有关。
• 哈希算法是不可逆的，而加密算法是可逆的。
在加密算法中又分为对称加密（symmetric encryption）和非对称加密（asymmetric encryption）。非对称加密算法中，加密密钥和解密密钥是不同的，分为私钥和公钥，我们熟知的 RSA 就是一种非对称加密算法。而对称加密中，加密和解密都是用同一个密钥，如 AES / DES。从性能上来说，非对称加密相对于对称加密要慢很多。在 HTTPS 中，认证过程使用了非对称加密算法，非认证过程中使用了对称加密算法。
前端加密的意义
在 HTTP 协议下，数据是明文传输，传输过程中网络嗅探可直接获取其中的数据。 如用户的密码和信用卡相关的资料，一旦被中间人获取，会给用户带来极大的安全隐患。另一方面在非加密的传输过程中，攻击者可更改数据或插入恶意的代码等。HTTPS 的诞生就是为了解决中间人攻击的问题，但如今 HTTPS 的使用情况在国内并不乐观，基本是因为成本或者性能的考量。那么问题来了，如果仍然使用 HTTP 协议怎么样一定程度保证用户的数据安全？ 前端加密，即在数据发送前将数据进行哈希或使用公钥加密。如果数据被中间人获取，拿到的则不再是明文。
设想在如今公共 WIFI 流行的今天，一旦某一个 AP 的流量被攻击者劫持，如果密码和用户名都是明文，那么攻击者将轻而易举的使用这些资料进行 Replay 登录。更糟糕的是很多用户在不同的网站使用相同的账号信息，用户的隐私荡然无存。作为网站服务提供者，网站设计和开发人员应该为用户提供相对安全的服务，这是一种责任也是一种情怀。
另外如果前端使用哈希算法，不仅可以帮助后端分担部分计算压力，还可以增加撞库成本。具体的讨论将在下文继续。
如何加密
前面说过使用 JavaScript 加密有两种方式，一是使用哈希进行信息摘要，一种是使用非对称加密。在国内的知名站点中，这两种方式都有人使用。接下来我们分别来深入了解加密过程，探讨下如何应对不同的场景。
哈希“加密”
为了避免传输过程中的明文风险，前端可以在发送敏感数据前对其加密，如密码。由于哈希算法的不可逆性，中间人无法从截取的数据中得知用户的密码信息。但是这里有一个问题，攻击者仍然可以使用拿到的哈希值进行直接登录。使用前端加密如何避免中间人重放攻击？带着这个问题，我们回顾下后台如何验证用户。
很多站点后台对于用户密码处理也是用哈希算法，一方面因为不需要将密文解密成明文来比对密码，另一方面是一旦加密算法和密钥泄露，那么整个用户资料库就相当于明文存储了。如果前端传过来的是明文，那么在注册时将其哈希，存入数据库。登录时，将密码哈希和数据库对应的数据比对，若一致则说明密码正确。
如果我们使用 Salt 是否可以解决问题？如果前端传过来的是加了 salt 的哈希值，我们需要后端存有同一份 salt ，用其和数据库的加密密码哈希，然后与前端传过来的哈希值比对。两个过程的对比见下图：

很容易知道，如果 Salt 不是每次登陆不同，那么攻击者仍可以使用加密后的密码进行直接登陆，所以必须使用动态 Salt。动态 Salt 有很多方法，可以是动态的 Token，也可以直接使用现成的验证码。 这当中使用验证码是对后台系统改动较小且效果不错的，我们来看看怎么样结合验证码进行前端加密。
前端先将密码哈希，然后和用户输入的验证码进行哈希，得到的结果作为密码字段发送给服务器。服务器先确认验证码正确，然后再进行密码验证，否则直接返回验证码错误信息。

这种实践保证了密码在传输过程中的资料安全，即使攻击者拿到了数据也无法重放。图形化验证码更是增加了难度。另一方面该实践大大增加了撞库的成本。
前端加密一定程度保障了传输过程中的资料安全，那么会不会有对两端（客户端和服务器）有安全帮助呢？有帮助，使用一些前端加密手段，可以加大拖库后的数据破解的难度。但是之前介绍的验证码方法不具有这样的功能，因为数据库存的仍是明文密码哈希后的结果，那么攻击者可以绕过前端加密，可以直接暴力破解。
使用怎么样的前端加密方法可以增大拖库后的数据破解难度？从两个方面分别去思考，一是降低破解速度，二是需要前端加密结果影响数据库的数据存储。数据被暴力破解出来的时间与哈希算法速度负相关。我们知道暴力破解即是使用相同的算法把常用的字符组跑一遍，如果结果相同那么就猜中明文了。如果算法越快，便能更快的破解。例如 MD5 加密一次耗费1微秒，那么攻击者一秒钟就可以猜大约 100万个词组。所以为了减慢破解速度，我们需要增加破解的时间，一个直接的方法就是使用更慢的算法，我们可以把常用的MD5算法替换为 bcrypt，PBKDF2 等慢算法。
对于需要前端加密结果影响数据库的数据存储，即为后端加密把前端加密结果当做明文密码，那么存在库里的密码便是前端哈希加上后端加密的结果。由于慢的算法会增加服务器计算压力，当我们把一部分哈希工作拿到前端，即减慢了加密速度，减轻了服务器压力，也顺带完成了前端加密的工作。
加密速度减慢一定程度会降低用户体验，这也是一部分站点未启用 https 的原因之一。但是因为我们的前端加密只会用在不常使用的登录和注册上，所以不会影响网站整体的体验。
综上，我们可以使用更慢的算法，加之视前端哈希结果为明文密码，便可增加拖库破解的成本。既然增加了破解的成本，撞库的成本也同样增加了。为了避免攻击者先前使用前后端加密生成的新字典，我们需要加盐，并不定期更新盐值。下图文是使用过期 Salt 的方法描述：
前端加密使用定期刷新的 Salt，哈希后生成密文，再经过后端加密后即为用于比对的密文。数据库中的密码哈希值跟着 Salt 进行变化，前后端需要有一套salt的更新机制。

回顾前端哈希的方法，解决了中间人攻击重放、加大了拖库破解的难度。虽然这些方法都不能完全保证用户安全，但是作为站点服务者，应该视用户为上帝嘛。这些方法也不过就是几行代码的事，但是却能一定程度的避免了用户账号被盗等风险。
非对称加密
上文中我们讨论了前端的哈希加密以及应用的场景。对于十足的安全控来说，这样的措施对于有心的攻击者基本没有用。那么我们可以采用更强的措施保障传输中的敏感数据安全。
之前有说过加密算法分为对称加密和非对称加密，因为前端的透明性，使用JavaScript来进行对称加密是不可能的了，那么只剩下了非对称加密这个选择。经过笔者几天的调研发现，某鹅某浪的部分登录页面采用非对称加密对密码加密。这些站点目前都还是使用 http 协议，这样的安全措施一定程度保证了用户的密码安全。
前端使用非对称加密原理很简单，前后端共用一套加密解密算法，前端使用公钥对数据加密，后端使用私钥将数据解密为明文。中间攻击人拿到密文，如果没有私钥的话是没办法破解的。可能有人会指出加密算法一旦被破解，这一套安全措施就没用了。况且 JavaScript 的生成安全随机数还是个问题，所以其实这是用不了 https 的权衡之计。在没有 https 的情况下，使用 JavaScript 非对称加密或者 插件加密通讯是比较好的替代方法，后者优于前者。
安全不只情怀
作为一个前端开发者，我们眼里不应该只充斥各种框架，更不能被旁人一句没有意义的话给击退。任何解决方案都有其适用的范围，世界上根本就没有银弹，安全问题亦是如此。所以根据实际的情况采取符合自己的安全解决方案很重要，即使办法不是 100% 有效，也不能放弃那 1% 可以为用户保障安全的机会。
意义在于提升解密成本啊。
只要成本严重不及收益，自然就是安全有效的算法，自然就有加密的意义。
前端代码一般就是混淆，这个也只是为了加大解读成本而已，并非不可解。
案例
难道你们没有遇到这种情况吗，自己想做个模拟登录的客户端，然后找到post的数据发现完全是加密过的，更气的是，还是特么用随机生成的钥匙对称加密了，虽然说这样做真的没有对密码安全有太大意义（因为js文件是人人都能看的），但是你需要从他那一千多行的js代码中找到他加密的方式，然后找出post的那一大串参数都是干什么的，对没错，就是微博爸爸，所以，有没有大佬说一下微博前端对密码的加密方式？？？
小白我来说说我的看法，前端加密有没有用，我觉得有用啊。大家不要忘了，犯罪分子也是分等级的，前端加密起码将一部分人拦截了，md5,sha1我记得用来作数据指纹多一点啊，当然目前来说最好的当然是用https啦，最后想说一句，也是一部电影的名字，没有绝对安全的系统！现在的加密过程是这样的:
1.客户端先向服务端请求公钥
2.客户端生成AES秘钥用公钥加密发送给服务端.
3.服务端用私钥解密再用AES秘钥加密自己发送回客户端
4.客户端解密后发现没有问题然后就用AES加密信息发送给服务端

错误的想法，认为Web前端密码加密没意义，或者说意义不大。
安全对抗，我们从攻击切面来谈。
B端，依赖操作系统，依赖用户的环境，Web前端做任何加密手段，只要宿主环境不安全，都是徒然（例如中毒了记录键盘操作）
传输层，HTTPS 已经是公认的传输层加密手段，必备，这个和Web前端密码加不加密扯不上关系。S端，后端有完整的安全对抗体系，我这里不展开。
我就问一句，给Web前端密码加密是为了防范什么？
@Rix Tox的场景，Client 手中的 K 从哪来？只有当存放 C 的 Server 拿不到 K 的时候，C才是安全的。@王集鹄的场景，其实是假设这个站点不可信，认为一套密码走天下的时候，总会有个别站点会泄露这个密码，所以总是手工hash一次密码。还是那句话，安全对抗要讲攻击点面，否则可以无限延伸开来。

没找到其他说有意义的具体案例，有我再补充。

PS1：给多一个非密码场景下的前端加密对抗案例，曾经3Q大战，攻防双方的战场是Web版的QQ。防守方不论怎么变化Web前端的防御手段，攻击者都能在短时间内破解，最终结果是，攻防双方在短时间内频繁迭代产品，变成一场非常消耗人力的拉锯战。

PS2：我看到很多评论并没有提及密码，没注意看题目是否改动过，但不论如何，在Web前端做加密始终收益不大，不如跳出来多从产品层面思考攻击者的利益诉求，从源头进行控制。