程式設計師必備基礎：如何安全傳輸儲存使用者密碼？
前言
我們開發網站或者APP的時候，首先要解決的問題，就是「如何安全傳輸和儲存使用者的密碼」。一些大公司的使用者資料庫洩露事件也時有發生，帶來非常大的負面影響。因此，如何安全傳輸儲存使用者密碼，是每位程式設計師必備的基礎。本文將跟大家一起學習，如何安全傳輸儲存使用者的密碼。
公眾號：「撿田螺的小男孩」（一起討論密碼傳輸儲存問題）
1. 如何安全地傳輸使用者的密碼
要拒絕使用者密碼在網路上裸奔，我們很容易就想到使用https協議，那先來回顧下https相關知識吧~
1.1 https 協議
「http的三大風險」
為什麼要使用https協議呢？「http它不香」嗎? 因為http是明文資訊傳輸的。如果在茫茫的網路海洋，使用http協議，有以下三大風險：
❝❞
竊聽/嗅探風險：第三方可以截獲通訊資料。 資料篡改風險：第三方獲取到通訊資料後，會進行惡意修改。 身份偽造風險：第三方可以冒充他人身份參與通訊。
如果傳輸不重要的資訊還好，但是傳輸使用者密碼這些敏感資訊，那可不得了。所以一般都要使用「https協議」傳輸使用者密碼資訊。
「https 原理」
https原理是什麼呢？為什麼它能解決http的三大風險呢？
❝https = http + SSL/TLS, SSL/TLS 是傳輸層加密協議，它提供內容加密、身份認證、資料完整性校驗，以解決資料傳輸的安全性問題。
❞
為了加深https原理的理解，我們一起復習一下「一次完整https的請求流程」吧~
❝❞
客戶端發起https請求
伺服器必須要有一套數字證書，可以自己製作，也可以向權威機構申請。這套證書其實就是一對公私鑰。
伺服器將自己的數字證書（含有公鑰、證書的頒發機構等）傳送給客戶端。
客戶端收到伺服器端的數字證書之後，會對其進行驗證，主要驗證公鑰是否有效，比如頒發機構，過期時間等等。如果不通過，則彈出警告框。如果證書沒問題，則生成一個金鑰（對稱加密演算法的金鑰，其實是一個隨機值），並且用證書的公鑰對這個隨機值加密。
客戶端會發起https中的第二個請求，將加密之後的客戶端金鑰(隨機值)傳送給伺服器。
伺服器接收到客戶端發來的金鑰之後，會用自己的私鑰對其進行非對稱解密，解密之後得到客戶端金鑰，然後用客戶端金鑰對返回資料進行對稱加密，這樣資料就變成了密文。
伺服器將加密後的密文返回給客戶端。
客戶端收到伺服器發返回的密文，用自己的金鑰（客戶端金鑰）對其進行對稱解密，得到伺服器返回的資料。
「https一定安全嗎？」
https的資料傳輸過程，資料都是密文的，那麼，使用了https協議傳輸密碼資訊，一定是安全的嗎？其實「不然」~
❝❞
比如，https 完全就是建立在證書可信的基礎上的呢。但是如果遇到中間人偽造證書，一旦客戶端通過驗證，安全性頓時就沒了哦！平時各種釣魚不可描述的網站，很可能就是黑客在誘導使用者安裝它們的偽造證書！ 通過偽造證書，https也是可能被抓包的哦。
1.2 對稱加密演算法
既然使用了https協議傳輸使用者密碼，還是「不一定安全」，那麼，我們就給使用者密碼「加密再傳輸」唄~
加密演算法有「對稱加密」和「非對稱加密」兩大類。用哪種型別的加密演算法「靠譜」呢？
❝對稱加密：加密和解密使用「相同金鑰」的加密演算法。
❞
常用的對稱加密演算法主要有以下幾種哈：
如果使用對稱加密演算法，需要考慮「金鑰如何給到對方」，如果金鑰還是網路傳輸給對方，傳輸過程，被中間人拿到的話，也是有風險的哦。
1.3 非對稱加密演算法
再考慮一下非對稱加密演算法呢？
❝「非對稱加密：」 非對稱加密演算法需要兩個金鑰（公開金鑰和私有金鑰）。公鑰與私鑰是成對存在的，如果用公鑰對資料進行加密，只有對應的私鑰才能解密。
❞
常用的非對稱加密演算法主要有以下幾種哈：
❝如果使用非對稱加密演算法，也需要考慮「金鑰公鑰如何給到對方」，如果公鑰還是網路傳輸給對方，傳輸過程，被中間人拿到的話，會有什麼問題呢？「他們是不是可以偽造公鑰，把偽造的公鑰給客戶端，然後，用自己的私鑰等公鑰加密的資料過來？」 大家可以思考下這個問題哈~
❞
我們直接「登入一下百度」，抓下介面請求，驗證一發大廠是怎麼加密的。可以發現有獲取公鑰介面，如下:
再看下登入介面，發現就是RSA演算法，RSA就是「非對稱加密演算法」。其實百度前端是用了JavaScript庫「jsencrypt」，在github的star還挺多的。
因此，我們可以用「https + 非對稱加密演算法（如RSA）」 傳輸使用者密碼~
2. 如何安全地儲存你的密碼？
假設密碼已經安全到達服務端啦，那麼，如何儲存使用者的密碼呢？一定不能明文儲存密碼到資料庫哦！可以用「雜湊摘要演算法加密密碼」，再儲存到資料庫。
❝雜湊摘要演算法： 只能從明文生成一個對應的雜湊值，不能反過來根據雜湊值得到對應的明文。
❞
2.1 MD5摘要演算法保護你的密碼
MD5 是一種非常經典的雜湊摘要演算法，被廣泛應用於資料完整性校驗、資料（訊息）摘要、資料加密等。但是僅僅使用 MD5 對密碼進行摘要，並不安全。我們看個例子，如下：
public class MD5Test {
public static void main(String[] args) {
String password = "abc123456";
System.out.println(DigestUtils.md5Hex(password));
}
}
執行結果：
0659c7992e268962384eb17fafe88364
在MD5免費破解網站一輸入，馬上就可以看到原密碼了。。。
試想一下，如果黑客構建一個超大的資料庫，把所有20位數字以內的數字和字母組合的密碼全部計算MD5雜湊值出來，並且把密碼和它們對應的雜湊值存到裡面去（這就是「彩虹表」）。在破解密碼的時候，只需要查一下這個彩虹表就完事了。所以「單單MD5對密碼取雜湊值儲存」，已經不安全啦~
2.2 MD5+鹽摘要演算法保護使用者的密碼
那麼，為什麼不試一下MD5+鹽呢？什麼是「加鹽」？
❝在密碼學中，是指通過在密碼任意固定位置插入特定的字串，讓雜湊後的結果和使用原始密碼的雜湊結果不相符，這種過程稱之為“加鹽”。
❞
使用者密碼+鹽之後，進行雜湊雜湊，再儲存到資料庫。這樣可以有效應對彩虹表破解法。但是呢，使用加鹽，需要注意一下幾點：
❝❞
不能在程式碼中寫死鹽，且鹽需要有一定的長度（鹽寫死太簡單的話，黑客可能註冊幾個賬號反推出來） 每一個密碼都有獨立的鹽，並且鹽要長一點，比如超過 20 位。(鹽太短，加上原始密碼太短，容易破解) 最好是隨機的值，並且是全球唯一的，意味著全球不可能有現成的彩虹表給你用。
2.3 提升密碼儲存安全的利器登場，Bcrypt
即使是加了鹽，密碼仍有可能被暴力破解。因此，我們可以採取更「慢一點」的演算法，讓黑客破解密碼付出更大的代價，甚至迫使他們放棄。提升密碼儲存安全的利器~Bcrypt，可以閃亮登場啦。
❝實際上，Spring Security 已經廢棄了 MessageDigestPasswordEncoder，推薦使用BCryptPasswordEncoder，也就是BCrypt來進行密碼雜湊。BCrypt 生而為儲存密碼設計的演算法，相比 MD5 要慢很多。
❞
看個例子對比一下吧：
public class BCryptTest {
public static void main(String[] args) {
String password = "123456";
long md5Begin = System.currentTimeMillis();
DigestUtils.md5Hex(password);
long md5End = System.currentTimeMillis();
System.out.println("md5 time:"+(md5End - md5Begin));
long bcrytBegin = System.currentTimeMillis();
BCrypt.hashpw(password, BCrypt.gensalt(10));
long bcrytEnd = System.currentTimeMillis();
System.out.println("bcrypt Time:" + (bcrytEnd- bcrytBegin));
}
}
執行結果：
md5 time:47
bcrypt Time:1597
粗略對比發現，BCrypt比MD5慢幾十倍，黑客想暴力破解的話，就需要花費幾十倍的代價。因此一般情況，建議使用Bcrypt來儲存使用者的密碼
3. 總結
因此，一般使用https 協議 + 非對稱加密演算法（如RSA）來傳輸使用者密碼，為了更加安全，可以在前端構造一下隨機因子哦。 使用BCrypt + 鹽儲存使用者密碼。 在感知到暴力破解危害的時候，「開啟簡訊驗證、圖形驗證碼、賬號暫時鎖定」等防禦機制來抵禦暴力破解。
參考與感謝
如何正確儲存和傳輸敏感資料？[1] 如何加密傳輸和儲存使用者密碼[2]
公眾號
公眾號：「撿田螺的小男孩」 github地址：https://github.com/whx123/JavaHome
Reference
如何正確儲存和傳輸敏感資料？: https://time.geekbang.org/column/article/239150
[2]如何加密傳輸和儲存使用者密碼: https://juejin.cn/post/6844903604944371726#heading-8