序言

對於一個網站而言，用戶註冊登錄系統的重要性不言而喻，而該系統的安全性則可謂是重中之重。設計良好的註冊登錄系統可以保證即使在用戶客戶端被監聽、數據網絡傳輸被攔截、服務端數據被泄露的情況下，也能最大程度地保障用戶的密碼安全，從而保障用戶的資金財產安全。本文結合工程實踐，對用戶註冊登錄系統可能面臨的攻擊和風險點逐一進行分析，並給出對應的應對措施，最終得到一套切實可行的用戶註冊登錄設計方案。

五種常見的用戶密碼泄露方式

黑客可以通過監聽用戶的客戶端（app或pc瀏覽器）、攔截用戶網絡請求、非法入侵服務端數據庫、撞庫攻擊和釣魚攻擊等五種方式竊取用戶密碼。其中監聽客戶端包含如下手段（詳見黑客破解密碼的幾種方式）：

1、通過木馬對用戶使用的設備鍵盤進行監控，通過分析用戶的擊鍵信息即可破解用戶密碼；

2、對於使用鼠標和圖片錄入密碼的方式，黑客可以通過控制木馬程序對用戶的屏幕進行錄屏監控，從而獲取用戶密碼。

攔截用戶網絡請求可以細分爲如下手段：

1、客戶端監聽用戶請求，在http層和tcp層之間截取數據，以獲取用戶密碼（針對https，詳見https真的安全嗎）；

2、網絡傳輸鏈路上攔截用戶請求，獲取用戶密碼（僅針對http的明文密碼傳輸）；

3、網絡傳輸鏈路上攔截用戶請求，執行網頁替換或部分代碼替換，從而騙取用戶敏感信息。

非法入侵服務端數據庫是指黑客利用服務器的漏洞，非法訪問服務端的數據庫並竊取用戶賬號密碼等信息。

撞庫攻擊則是利用很多用戶在不同網站使用相同的帳號密碼，即黑客可以通過獲取用戶在A網站的賬戶密碼從而嘗試登錄B網站。也就是說，即使你自身的網站對用戶的密碼做了各種各樣的防護手段，也無法避免該用戶在其他網站的密碼被黑客竊取，從而導致該用戶在你網站上的密碼也被竊取（對於這個問題，後面會給出應對策略）。

釣魚攻擊是指黑客利用欺騙性的電子郵件和僞造的網站登錄站點來誘騙用戶輸入用戶名、密碼等敏感信息，從而竊取用戶密碼。其原理和前面提到的攔截用戶請求，執行網頁替換的方式非常相似。

密碼破解利器——彩虹表

本人的另一篇博客深入淺出彩虹表原理介紹了密碼破解利器——彩虹表。爲了更好地理解本文接下來介紹的內容，強烈建議先閱讀該博客中的內容。

參考博客中的方案分析

參考博客App登錄模塊密碼加密方案中給出了一種設計方案：

圖中的rule1和rule2方法實際上是對應的是MD5、SHA128、SHA256、SHA512、RipeMD、WHIRLPOOL等不可逆的哈希（hash）算法（關於哈希算法不可逆的原理介紹，詳見參考博客爲什麼說MD5是不可逆哈希算法）。

上述方案存在的致命問題是無法應對前面介紹的“非法入侵服務端數據庫”這種攻擊（由參考博客2018上半年國內外互聯網十大數據庫泄露事件可知，非法入侵數據庫是黑客批量獲取用戶賬號密碼的重要手段之一）。由圖中所示，用戶註冊時，在客戶端對明文pass加密得到passStr並保存在數據庫中，當黑客非法入侵到服務端數據庫並獲取到用戶的密碼passStr後，甚至都不需要破解以得到pass，而直接用passStr登錄即可。因而在參考博客加鹽hash保存密碼的正確方式中提到，即使客戶端做了哈希運算，服務端依然需要將得到的密文再進行hash。

此外，圖中的方案在登錄時採用了向服務器請求隨機鹽的方式來對明文進行加密的方案，而參考博客加鹽hash保存密碼的正確方式中卻反對使用這種方式，給出的原因是惡意的攻擊者可以通過這個邏輯來判斷一個用戶名是否有效。對於這個理由，你可能會不以爲然，因爲對於用戶請求隨機鹽的接口，服務器完全可以不校驗該用戶名是否存在，而只是臨時生成一個隨機鹽返回給客戶端，並將該鹽存儲到緩存中。當用戶用該鹽生成的密碼提交登錄請求時再進行校驗，並返回“用戶名或密碼錯誤”這樣的提示即可避免上述問題。對此，我們需要結合剛剛提到的“即使客戶端做了哈希運算，服務端依然需要將得到的密文再進行hash”來進行分析。由於服務端需要對客戶端的密文再進行一次哈希，如下圖所示：

圖示中，註冊時對明文A只使用了普通的hash，在服務端對密文B使用不同對哈希函數再次進行運算，得到密文C並存儲到數據庫。登錄時，客戶端先像服務端請求hash鹽，然後對明文A使用加鹽的hash，服務端得到了密文D。可問題是，這個時候我們無法驗證密文D的正確性！！爲此，我們不得不考慮在註冊時也使用加鹽hash，如下圖所示：

圖示中，我們註冊和登錄時都使用了加鹽hash，而且，爲了保證登錄時能校驗明文的正確性，我們必須使用和註冊時同樣的鹽，因此鹽值不能只是存儲中緩存中，而是需要同密文一起存儲到數據庫中。試想一下，此時用戶登錄，請求用戶鹽值，如果該用戶存在，則返回其鹽值，如果不存在，則不返回鹽值。黑客不就可以以此判斷該用戶是否合法了嗎？

至此，我們明白了，通過客戶端向服務端獲取鹽值的方案不合適，那麼具體應該怎麼辦呢？參考博客加鹽hash保存密碼的正確方式中提到：因爲我們已經在服務端進行了恰當的加鹽的hash。所以這裏使用用戶名跟特定的字符串(比如域名)拼接作爲客戶端的鹽是可以的。也就是說，參考博客加鹽hash保存密碼的正確方式推薦如下方案：

個人對此方案持反對意見。我們在客戶端加隨機鹽的目的是使客戶端到服務端之間的密碼安全。現在客戶端採用了加常量隨機鹽的方式，由參考博客深入淺出彩虹表原理可知，在彩虹表面前，常量隨機鹽的意義並不大。那麼該如何保障客戶端到服務端之間的密碼安全呢？

一個可行的方案是使用非對稱加密算法RSA（百度的註冊登錄使用的就是這個算法，RSA屬於非對稱加密算法，即加密解密使用的密鑰不是同一個。關於RSA算法的詳細原理見本人的另一篇博客RSA算法原理及其在HTTPS中的應用），具體來說就是用戶註冊登錄時，在提交註冊或登錄請求前先請求網站的公鑰，並使用公鑰對明文進行加密，服務端接收到密文之後，先用私鑰進行解密，然後再通過加鹽的哈希算法加密並存儲到數據庫中。即客戶端和服務端之間的鏈路通過RSA算法保證密碼的安全，而服務端仍然採用隨機鹽的哈希算法：

實際上，上述方案還存在一個問題：在服務端通過私鑰解密之後居然能看到用戶的明文密碼！！！這肯定是不能接受的！因而實際上，我們在客戶端使用RSA加密之前，會先使用哈希算法對明文進行加密，具體流程如下所示：

由圖可知，整個鏈路，除了用戶輸入時是明文之外，其它地方都是密文，從而可以較好地保證用戶的密碼安全。爲了便於後續描述，我把該方案簡稱爲“哈希+RSA+隨機鹽哈希”方案。

其實到這裏，密碼的安全程度已經非常高了，可以直接應用於企業網站系統了。但如果還想在此基礎上進一步提高其安全性，還可以往哪個方向努力呢？

可以看到，上述方案對於黑客而言，由於RSA算法的公鑰是公開的，因而獲取到明文A和獲取到密文L是等價的！！假設黑客通過非法入侵數據庫得到了用戶的密文M及其隨機鹽salt值，在掌握了服務端加密算法hash2的情況下，就可以利用彩虹表對單個用戶進行暴力破解（儘管破解成本很高），最終只需要獲取密文L即可。

對此，參考博客加鹽hash保存密碼的正確方式中也提到了：只要攻擊者能夠驗證一個猜測的密碼是正確還是錯誤，他們就可以使用字典或者暴力攻擊破解hash。更深度的防禦方法是加入一個保密的key(secret key)進行hash，這樣只有知道這個key的人才能驗證密碼是否正確。這個思路可以通過兩種方式來實現。一種是hash通過加密算法加密比如AES，或者使用基於key的hash函數(HMAC)。

以AES（AES、DES等都屬於對稱加密算法，即加密解密的祕鑰是同一個，詳見參考博客用不可逆加密純客戶端實現加密及驗證）爲例（HMAC方案類似，不再贅述），具體方案如下：

該方案是在“哈希+RSA+隨機鹽哈希”方案的基礎上再加了一層AES對稱加密。對於對稱加密的密鑰，博客加鹽hash保存密碼的正確方式中要求將AES使用的加密key單獨存儲在一個外部系統中，比如專門用來進行密碼驗證的物理隔離的服務器。

試想一下，黑客通過非法入侵數據庫獲取了密文N和隨機鹽，並且掌握了服務端使用的hash2和AES算法（由於AES的加密key在獨立的數據庫，因而此處假設黑客只是掌握了加密算法，而沒有獲取到加密key），那麼他是否有可能通過暴力破解以得到密文L呢？

假設黑客猜測密文N破解後的密文爲P，這裏需要驗證P=L。爲此，黑客首先將密文P使用hash2算法執行加鹽哈希，得到的密文假設爲Q，由於黑客不知道AES算法的加密key，因而無法對Q進行運算，也就無法驗證Q經過AES(Q, key)加密之後的結果和密文N是否相等。由此可知，只要保護好了key不被泄密，那麼黑客的暴力破解就是無效的，因爲他無法驗證猜測的密碼是否正確。我們將該方案簡稱爲“哈希+RSA+隨機鹽哈希+AES”方案。當然，對應的還有“哈希+RSA+隨機鹽哈希+HMAC”方案。

針對五種泄密方式的分析

本節內容我們來分析上一節得到的三個方案在面對前面介紹的五種泄密方式時的表現。

很顯然，該方案對於前面提到的監聽客戶端的鍵盤和屏幕等攻擊手段無能爲力；對於攔截用戶網絡請求的三種方式中，能避免第一和第二種攻擊，但無法解決網頁替換攻擊（所幸採用https可以解決第二種和第三種攻擊，因而本文得到的兩個方案在基於https進行加密傳輸的情況下可以避免攔截用戶網絡請求的各種攻擊）；對於黑客非法入侵服務端數據庫，由於密文都是經過加密的，就算使用彩虹表也難以破解；以上加密方案對於撞庫攻擊和釣魚攻擊均無能爲力。

至此可知，用戶註冊登錄系統採用本文最終的三種方案結合https進行網絡傳輸，可以解決用戶網絡請求攔截攻擊和服務端數據庫非法入侵，但還是無法避免客戶端監聽攻擊、撞庫攻擊和釣魚攻擊！！！

其實細想一下，以上三種攻擊，已經完全超出了註冊登錄系統本身所能保護的範圍。比如你無法絕對保證用戶使用的客戶端是安全的，你也無法保證用戶在不同網站使用的賬號密碼是不一樣的，你也無法保證用戶一定不會訪問一個釣魚網站從而導致密碼泄露。因而對於以上三種攻擊，我們也不要再奢望通過增加註冊登錄系統的複雜性而有所改善，完成這個工作的應該另有其人。

風控系統——網站的保護傘

絕大多數的大中型互聯網公司都有風控系統，該系統最重要的工作就是對用戶操作行爲進行風險評估，以保證在用戶的密碼已經被泄漏的情況下，最大限度地保護用戶的資金財產安全。風控系統具體的操作思路是：建立用戶行爲畫像，即存儲用戶日常登錄的終端設備的ip地址、設備唯一標識、用戶所在地、常用往來交易賬戶等信息。當用戶出現異常操作時，比如異地登錄、換新設備登錄等，則該操作會被判定爲風險操作，從而通過增加郵件、短信等驗證機制以確認是用戶本人的操作行爲，並適時提醒用戶更新密碼。

總結

至此可知，本文最終得到的三個加密方案“哈希+RSA+隨機鹽哈希”、“哈希+RSA+隨機鹽哈希+AES”、“哈希+RSA+隨機鹽哈希+HMAC”結合“基於https的加密傳輸”方案可以較好地保障系統自身的數據安全，但無法保障自身系統以外的數據安全。而風控系統則負責保證在用戶的密碼已經被泄漏的情況下，最大限度地保護用戶的資金財產安全。兩相結合，就可以有效地保障用戶的資金財產安全。

參考博客：

1、http://www.360doc.com/content/18/0318/06/415885_738036451.shtml 黑客破解密碼的幾種方式

2、https://www.cnblogs.com/guanghe/p/10671666.html https真的安全嗎，加密登錄其實不簡單

3、https://www.jianshu.com/p/26234e36869c App登錄模塊密碼加密方案

4、https://blog.csdn.net/Saintyyu/article/details/102583941 深入淺出彩虹表原理

5、https://wooyun.js.org/drops/%E5%8A%A0%E7%9B%90hash%E4%BF%9D%E5%AD%98%E5%AF%86%E7%A0%81%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F.html 加鹽hash保存密碼的正確方式

6、https://www.sohu.com/a/252091442_464012 盤點： 2018上半年國內外互聯網十大數據庫泄露事件

7、https://blog.csdn.net/Saintyyu/article/details/55806247 RSA算法原理及其在HTTPS中的應用

8、https://blog.csdn.net/Saintyyu/article/details/102641627 爲什麼說MD5是不可逆哈希算法

9、https://blog.csdn.net/hj7jay/article/details/80221060 HTTPS連接過程以及中間人攻擊劫持

10、https://www.jianshu.com/p/f693cbb87f9e 用不可逆加密純客戶端實現加密及驗證

11、https://www.cnblogs.com/chromebook/p/4112329.html RSA、DSA以及ECC