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加密方法知道密文