javascript - 一些网站在用户提交登录时将密码框中的密码用js进行了一次不可逆加密，然后提交。这样做有必要么？有什么好处和坏处？

这些网站的流程大概是这样的:

用户注册时:

1. 用户填写密码

2. 用户点击提交

3. 提交前在前端将密码加密

4. 存入数据库前再将密码加密

用户登录时:

1. 用户填写密码

2. 用户点击提交

3. 提交前在前端将密码加密

4. 将密码传人服务器并再次加密

5. 比对数据库中的密码

我觉得这样做只不过能防止别有用心的人获取你的明文密码，但他们仍然能够在不知道明文密码的情况下使用截获的密文构造请求登录

然而仍然有些网站(http网站)在这样做，那么这样做有必要么？有什么好处坏处？

这样做显然不能替代https

回复内容：

这些网站的流程大概是这样的:

用户注册时:

1. 用户填写密码

2. 用户点击提交

3. 提交前在前端将密码加密

4. 存入数据库前再将密码加密

用户登录时:

1. 用户填写密码

2. 用户点击提交

3. 提交前在前端将密码加密

4. 将密码传人服务器并再次加密

5. 比对数据库中的密码

我觉得这样做只不过能防止别有用心的人获取你的明文密码，但他们仍然能够在不知道明文密码的情况下使用截获的密文构造请求登录

然而仍然有些网站(http网站)在这样做，那么这样做有必要么？有什么好处坏处？

这样做显然不能替代https

以前做身份认证的时候有想过前端加密，感觉很鸡肋，没多大作用。

对于服务器来说，前端加密后的数据就是用户的密码，一旦被抓包，黑客拿到了前端加密后的数据，一样可以伪装登录

如果安全性要求高的，还是老老实实用https，虽然它也有被攻击的可能。

全站https的话会导致所有的http资源出现报警，因为HTTPS要求全程加密，哪怕是一张图片。

在前端加密的话可以保证传输过程中密码是传输的密文，也就是说，除了密码所有者，没人知道密码是什么，就算是开发程序的人也不知道。
这样就算别人抓到你的http包，也无法解密（暴力破解除外）

唯一的好处是你的数据库在被脱裤情况下，不会影响到用户在其他网站上的密码（俗称撞库）
其他都没什么用，直接重放攻击一下就可以伪造用户登录了，比如说在http情况下中间人攻击，截获了用户的密码，我不需要知道原密码是什么，只需要再次用相同的密文发送请求同样可以伪造用户登录
https网站做下加密我还可以理解，就是我说的唯一好处
http网站这样做完全是脱了裤子放屁，一点用都不能保证用户安全，况且如果前端加密算法是可逆的话，这样做也没用，同意可以通过还原js加密方法知道密文