登錄，是做web開發的程序員做項目第一接觸到的模塊，看似簡簡單單的登錄背后囊括了編程知識的方方面面。
登錄安全嗎？密碼會不會泄露？
明文傳輸時代
互聯網開始的時候，登錄確實是使用明文校驗的，甚至數據源中存的也是明文密碼，后來隨着黑客的誕生，和隱私安全保護的考慮，密碼開始使用密文存儲。
於是認證的過程變成了這樣，用戶注冊時，數據庫保存了加密的密碼，當用戶登錄時，web系統接收到用戶的明文密碼，系統加密后與數據庫中的加密密碼再作比較。
可是，我們發現傳輸密碼的過程還是傳的明文！只要我截獲了你注冊或登錄的數據包，你的密碼就泄露了。
https時代
https誕生了，它不僅可以將你要傳輸的密碼加密傳輸，甚至你的所有請求數據在網絡傳輸中都是加密的，別人拿到數據包也沒用。
但，https真的安全嗎？
https是加密傳輸， 所以抓到包也沒有用， 是密文的。 真是的這樣嗎？ 有人做實驗抓到了某網站登錄的密碼， 是明文的，結果多試幾個， 結果抓到了許多https傳明文密碼。
為什么用https抓包, 還是能看到明文內容呢？ 這里我們要理解https的棧流程， 梳理一下就知道， 加密層位於http層和tcp層之間， 所以抓到的http層的數據並沒有加密。 同理， 在后台接收端， 經歷解密后， 到達http層的數據也是明文。 要注意， https不是對http報文進行加密， 而是對傳輸數據進行加密， 最終還原http原始報文。
這里不得不再次強調，https保證的是傳輸過程中第三方抓包看到的是密文。客戶端和服務端，無論如何都可以拿到明文。其實大多數人認為https加密傳輸安全是因為沒有真正理解https的真實原理。
自定義加密傳輸時代
上邊說道，https能避免傳輸的過程中，如果有人截獲到數據包只能看到加密后的信息，但是防不了在服務端和客戶端截取數據的人。服務器端自不必說，如果黑客都能取到服務器的數據了那你加不加密估計也沒什么意義了，但客戶端就不一樣了，許多密碼泄露都是在客戶端泄露的。所以客戶端密碼保護很重要！顯然https這點就做不到了。那么，就只有寫程序的人自己定義加密方式了。
我們看百度的登錄的過程
我們可以很easily的看到，在登錄之前，百度前端獲取了一次公鑰，用公鑰加密后傳輸加密后的密文密碼，這樣做到了全流程加密傳輸。