國內大多數網站的密碼在 post 傳輸過程中都是明文的，這正常嗎？

所以說，插件在很多時候也都是自欺欺人。可能阻止了一部分流行的病毒的行為，但是有針對性的攻擊是否也能阻止，難說。只考慮網路安全的話用https即可，不需要另外的插件。

更進一步地說，考慮病毒的影響的話，某些直接使用自己的客戶端的驗證方式也無法保證安全。比如某個病毒作者自己做一個登陸框，替換掉QQ.exe，QQ自身沒有任何防範方法。只是用戶很快就會發現問題而已，因為登錄不上去。對QQ可能影響不大，但是想像一下要是有銀行用類似的方法，病毒可以在攻擊者得到密碼之後，立即破壞系統文件，切斷用戶的網路，可以稍微用藍屏之類的方式掩飾一下，避免用戶很快直接聯繫銀行，然後攻擊者立即將用戶的存款轉出。只是病毒的體積可能有些大，看現在的網速可能也不是很大的問題。

網速比較快的話，USB Key也可以做個程序遠程與硬體交互，攻擊者那邊再裝個虛擬的硬體驅動，實在不行就用虛擬機。有些設備可能解決了這些問題，畢竟網路不太可能完全沒有延遲，而且帶寬有限。有些設備可能沒有，或者目的僅僅是避免依賴於密碼。

但是比如說，使用手機簡訊驗證，而且保證手機不中毒，或者比如說使用帶有屏幕的USB Key，那麼應該是安全的。不過個人認為受盜號影響不大的普通網站沒必要在用戶自己中毒造成的問題上下太多功夫。這是用戶自己和殺毒軟體的責任。

另外關於明文存儲密碼，有些人有概念錯誤（以下專業的人可以不必看）。明文存儲密碼不是要避免有人用用戶的密碼去登錄其它網站，而是在網站自身的資料庫泄露之後，避免有人直接用泄露的密碼直接登錄自己的網站。「從技術上保證一個網站的密碼不能用於登錄另一個網站」，不應該是網站的責任，而是瀏覽器應該做的事，雖然現在沒有哪個瀏覽器做了這件事。

伺服器的資料庫的所謂密碼加密，其實是不可逆的hash，hash之後直接與資料庫比較。但是js加密（或者https加密）要是用同樣的方法的話，攻擊者得到加密之後的內容，就可以跳過js加密的步驟，用加密後的內容直接通過驗證。所以任何客戶端的加密方法，都應該保證一個加密後的數據不能重複使用兩次。使用的演算法一般應該是可逆的，也有一些其它方案，比如兩次操作順序可交換的不可逆演算法。

所以以上就有三種不同意義的加密：1.用戶在不同網站上使用不同的密碼；2.傳輸過程中的加密；3.網站自身資料庫的加密。如果要達到目的，任何兩個都不能共用同一加密過程。

第一條比起在瀏覽器上實現這個功能，現在似乎有個另外的趨勢是用一個賬號登錄多種服務。實際上有一些安全隱患，因為某些不重要的小網站可以用QQ、微博賬號登錄，某些購物網站一樣也可以用QQ、微博賬號登錄。這樣在某些明知不安全的環境，可能比如一些網吧，注重安全而又想登錄小網站的人就會比較困擾。

補充：本答案的主要目的是「稍微糾正一下其它答案中的問題。」太長無法作為評論，而且很多答案的問題相似，所以作為一個答案發出來，僅此而已。所以以上各段大體上說的也不是同一件事，也不都與題主的問題有關。如果對某一部分本來就沒有疑問，也沒有看到別人與此矛盾的說法，可以自行忽略。

關於病毒的部分，我沒有打算特別去說病毒的問題，也不認為一般網站應該考慮病毒的問題。只是因為看到有其他回答把插件和https相比較。我是說很多瀏覽器插件並不能完全代替https的作用，所以兩者很難直接比較。就算用js+插件的方式，如果不實現完全類似於https的功能的話，也很難達到https那樣的安全性。

大家的安全意識不強，有些互聯網公司為了減少成本，在安全方面能省就省，導致很多重要系統登陸頁面連最省錢最基礎的SSL證書也沒有安裝。

1、包被截留，無論密文有沒有加密，直接按數據發包，依舊能登陸沒有任何區別。
2、如果是做MD5處理，服務端直接校驗Hash值

if POST過來的值==資料庫的值：
通過


那麼被拖庫的話，根本不用跑彩虹表了，直接用密文登陸了。
當然，這點有更好的解決辦法就是客戶端發MD5值，服務端password欄位保存MD5(客戶端傳來的數據+salt)並校驗。
3、手機移動頁的問題，我自己做個人項目的移動頁一般Gzip後控制在20KiB以內（靜態結果頁、js、CSS等的綜合，不包含頁面圖片），如果要在移動頁上也做一個MD5，引入一個MD5處理函數，就10KiB了，當然這不是大問題，萬一窮鬼們為了省流量，用Opera Mini之類的壓縮、不支持JavaScript的瀏覽器呢？
因為我自己就是一個用EDGE網路，100MiB月流量的窮鬼，我相信雖然知乎大部分人看起來都很光鮮，但是像我這樣的窮鬼一定為數不少。

所以就這樣來看，如果發的包可以被截留，那麼做不做MD5加密，都不會影響黑客偽造登陸。
所以你這種想法還是Naive，同樣的發包可以被截留的環境，你設想的並不會更安全，反而削弱了用戶體驗。
如果不考慮用戶體驗來做前端安全這塊，該怎麼做呢？

我會在session里建立密碼與被打亂的小鍵盤的映射，然後把映射生成圖片發送到前端，用戶發送的密碼經過混淆，在後端進行校驗，校驗一次，然後銷毀映射。
這樣雙端加密，即使被抓包也是安全的。
或者直接https。

看到答案里有人提到用 MD5 代替明文，這樣做其實是沒有意義的，第一可以重放，第二可以用彩虹表。

這裡其實提到安全問題，對於安全問題應該分為以下幾種階段：
1、客戶端安全（表現為數據錄入時的安全）
2、客戶端到服務端之間信息傳輸安全（也就是你提到的數據傳輸時的安全）
3、服務端的安全（服務端密碼存儲的安全）

應該說是絕大多數網站因為安全界別的關係只要保證服務端安全就可以了，所以你看到的很多網站都是明文傳輸的！

如果非明文，有幾種做法：
1、HTTPS，做加密簽名
2、js加密後傳輸（不確定，因為很少這樣做，但我覺的應該是可以的）
3、做瀏覽器插件，進行數字信息保護。

但其中還有問題。
1、2都無法做到絕對的安全，因為鍵盤是可以程序監控的。智能保證客戶端到服務端傳輸過程中的安全。
3可以做模擬鍵盤，點擊輸入。相對來說無法做到鍵盤監控，而且傳輸數據也有保障。
2用JS加密因為JS腳本本身就是可下載的，所以加密方式泄露也會產生不安全問題。而且我很少看到有用JS加密後進行傳輸的。

其實能看出要做到絕對的安全，成本比較高。所以網站基本都會評估自己對帳號信息所要保證的安全級別再結合自己本身的業務來選擇做到什麼程度。

安全界別最高的，涉及到金錢交易，比如：電子商務，網銀等。都採用第3種做法。
安全界別稍高的，需要注意到信息丟失代碼的一些列影響，比如，微博的APP種的API KEY等信息丟失帶來的一系列後果和影響。
安全界別較低的，只要保證帳號在平台內足夠安全就可以了，比如：知乎、豆瓣等。因為密碼丟失本身不會帶來過於嚴重的問題，內容丟失、剽竊、亂輸入相對來說影響較小，而且容易恢復。

所以一般明文傳輸的網站用戶協議裡面應該會包含用戶應該自己保證自己的帳號安全，如果是用戶丟失的（未到達服務端之前），後果由用戶承擔，如果網站弄丟了，則站方承擔責任。

明文傳輸成本較低，而且一些網站不需要那麼高級別的要求，再加上如果真用高級別的安全來要求一些不需要很高安全級別的網站，也會帶來一系列很麻煩的問題。你希望在你上知乎的時候下載安裝插件嗎？估計你會逼瘋。

現在的程序員都懶+沒需求去做。
有錢並且認識到用戶密碼是用戶隱私的公司用ssl，小公司沒錢或者沒需求。

其實做這個也非常簡單，關鍵是非對稱加密和鹽：post之前js生成一個鹽（後端發鹽的安全性高點），然後把密碼和鹽用非對稱加密演算法的公鑰加密，然後post提交鹽和加密之後的密碼，後端接收之後用鹽和私鑰解密就得到用戶的輸入密碼了。

至於防重放，關鍵是時間戳與簽名。可以由後端發鹽和時間戳和公鑰，然後由js計算與伺服器的時間差，等提交的時候提交一個與後端當前時間誤差極小的時間戳和鹽的公鑰簽名，後端驗證時間戳誤差在安全範圍之內且當前時間戳大於上次請求的時間戳，然後簽名一致即可。

防中間人在理論上不可行，主要是http協議是無狀態，中間人很容易就能偽造請求，並且前端想知道這個請求來自可信的後端是不可能。據我目前所了解的知識來說，ssl可以實現相對安全，前提是由人來確保根證書的可信列表以及識別瀏覽器給出的證書警告信息。

不過題主的本意我理解為預防http協議下網路嗅探等直接暴露明文密碼的方式，只要實現了用戶密碼加密與防重放，其實就夠了。

提供一個方案供參考。
客戶端做md5/sha1，post到服務端；
服務端再對post過來的內容做md5/sha1；
最後跟資料庫中保存的密碼比對。

-----------------------------------------------------
這個方案只能保證即使後台資料庫泄露，也不會暴露用戶的初始密碼。
評論中知友提到的線路被監聽的情況，這方案依舊無力。