密碼泄漏，不可小視

圖解網(wǎng)站：https://xiaolincoding.com/

今天，跟大家聊聊注冊和登錄的原理，主要討論安全問題。安全是一個公司生死存亡的關(guān)鍵，華為和騰訊都有大量的技術(shù)人員，來保障業(yè)務(wù)的安全。

在工作中，一旦遇到了安全問題，必須立即處理，誰都擔(dān)不起安全責(zé)任。安全攻防是一個動態(tài)博弈，沒有攻不破的防守，也沒有防不住的進(jìn)攻。

而且，在面試中，安全問題也是必然會涉及到的，比如最基本的AES、RSA、TLS、HTTPS、注冊登錄、密碼存儲等知識，我們必須熟悉。

注冊APP時，你填寫用戶名和密碼，點擊提交后，APP后臺肯定需要“存儲你的用戶名和密碼”，為后面的登錄驗證做準(zhǔn)備。

登錄APP時，你輸入用戶名和密碼，APP后臺就能驗證你輸入的用戶名和密碼，與當(dāng)時注冊APP時的用戶名和密碼是否匹配。

那么，有沒有思考過這個問題：APP后臺開發(fā)的程序員GG們，能偷窺到你的密碼嗎？他們會盜用你的賬號和密碼進(jìn)行登錄嗎？黑客攻擊APP后臺后，能盜用你的賬號和密碼嗎？

顯然，這是不允許的。沒有辦法在道德和法律的規(guī)范下嚴(yán)格禁止這樣的行為，那就要從技術(shù)機制上禁止，要確保即使在數(shù)據(jù)庫和程序代碼被盜走的情況下，壞人也無法破解密碼。

一. 密碼直接明文存儲

如果在APP后臺數(shù)據(jù)庫中直接存儲用戶名和密碼，那么黑客可就要在睡夢中笑醒了，比如：

那么，有沒有網(wǎng)站中招呢？當(dāng)然有！當(dāng)年CSDN博客首當(dāng)其沖，當(dāng)時的聲明如下：

二. 密碼加密存儲

自然地，我們想到對密碼進(jìn)行加密存儲。不過，這種方式也挺業(yè)余的，既然能加密，就有辦法解密，同樣存在密碼被盜的風(fēng)險，如果APP后臺能以某種方式還原密碼，那就是流氓系統(tǒng)哈。

我們有這樣一個常識：當(dāng)用戶忘記密碼后，正確做法不是APP后臺告訴用戶密碼是多少(因為APP后臺壓根就不應(yīng)該知道用戶的密碼)，而應(yīng)該讓用戶重新設(shè)置密碼?；叵胍幌?，是不是如此？

三. 密碼哈希存儲

哈希函數(shù)，單向散列，且?guī)缀醪粵_突，故可以考慮對密碼進(jìn)行哈希變換后存儲。

從理論上講，即使哈希值yyyyyy被盜走，別人也難以還原成原來的abcd123了，因為哈希函數(shù)不可逆。這樣貌似就實現(xiàn)了密碼的安全存儲，不過，有點太天真了。

如果數(shù)據(jù)庫和程序代碼被盜，從理論上講，難以用yyyyyy反推出密碼abcd123, 但黑客可以用彩虹表攻擊，分分鐘就能破解出密碼abcd123, ?彩虹表攻擊的圖示如下：

我來簡單解釋一下：

黑客對一些常用密碼進(jìn)行哈希，形成一張很大的資料表，一旦黑客盜走數(shù)據(jù)庫中的密碼哈希值yyyyyy, 就可以在資料表中進(jìn)行查找，很快能知道密碼是abcd123.

這個資料表，就是所謂的彩虹表。理論上不可反解的哈希函數(shù)，被狡猾的黑客給“破解”了，并且得到了密碼。所以，直接用哈希的方式存儲密碼，是肯定不行的。

四. 密碼多次哈希存儲

有的朋友可能覺得彩虹表能實現(xiàn)攻擊，主要是因為只用一次哈希，那么多加幾次哈希，是不是就解決問題了呢？

顯然不是。多次哈希后，一旦黑客拿到你多次哈希的程序代碼和數(shù)據(jù)庫，便可構(gòu)造多重彩虹表，分分鐘破解密碼:

五. 固定鹽值哈希存儲

思考一下，現(xiàn)在的問題是，要抗彩虹表攻擊，可以考慮這么做：

P?=?hash(user?+?hash(password))?

此處的user就是用戶名，用作鹽值，增加了黑客的破解難度，因為黑客需要針對每個user做一張?zhí)囟ǖ亩夭屎绫?，才有可能破解?/p>

即便如此，在攻擊一些重要user時，黑客可能感覺值得嘗試一下，也是能分分鐘進(jìn)行破解的。所以，用固定鹽還是存在較大風(fēng)險。

六. 隨機鹽值哈希存儲

既然固定鹽值不好，那就用隨機鹽吧，于是可以考慮這么做：

P?=?hash(salt?+?hash(password))?

這個隨機鹽salt，需要存儲在APP后臺數(shù)據(jù)庫中?？蓡栴}是，APP和APP后臺需要使用相同的隨機鹽，那么APP是怎樣獲取APP后臺的隨機鹽呢？

這又涉及到一系列的加密算法和秘鑰管理問題，在實際系統(tǒng)中，有些公司就是這么做的。隨機鹽的引入，可以讓彩虹表失效，黑客只能“望鹽興嘆”。

七. BCrypt存儲

有沒有更簡潔且安全的做法呢？

有！用BCrypt吧。我覺得，BCrypt這個名字不太好，應(yīng)該叫bSHA，BCrypt是一個帶隨機鹽的哈希函數(shù)，在哈希值中，又?jǐn)y帶了鹽的信息，而且也是一種單向 Hash 加密算法，因此它不可被反向破解生成明文。

由于計算中使用了隨機鹽值，并且在密文中包含了 salt 值，默認(rèn)情況下每次生成的密文都是不同的。隨機密文帶來的好處是：避免了如果兩個人或多個人的密碼相同，密碼加密后保存到數(shù)據(jù)庫會得到相同的結(jié)果，以防破解一個就可以知道其他人的密碼。

BCrypt加密后的密文結(jié)構(gòu)如下圖所示：

其中密文結(jié)構(gòu)為：$是分割符， 2y是BCrypt加密版本號，10 是 cost 的值（代價因子，值越高，耗時就越長，值為10代表進(jìn)行，10 輪運算的鹽值，10 輪的意思是 2 的 10 次方哈希），緊隨其后的前 22 位是鹽值（salt），最后的字符串就是密碼的密文了。

因為 BCrypt 密文中包含鹽值（salt），所以在服務(wù)端就能從客戶端發(fā)送過來的哈希值中解析出 APP 端使用的隨機鹽值，該隨機鹽不需要被 APP 后臺數(shù)據(jù)庫存儲，減少了鹽值泄露的風(fēng)險。

使用 BCrypt 后，注冊登錄的邏輯圖如下：

而且，BCrypt 是一個相對較慢的哈希函數(shù)，我們可以通過調(diào)整 BCrypt 函數(shù)中的代價因子（cost）來控制函數(shù)的執(zhí)行時間，比如針對 8 位密碼，在代價因子為 14 的情況，執(zhí)行 BCrypt 需要 1 秒左右，而 MD5 只需要 0.8 毫秒。

因為 BCrypt 很慢，所以如果黑客想要通過窮舉的方式破解密碼，那么那些計算機在使用大量的 BCrypt 時性能就會很差，破解的時間成本就很高了。

參考《鳳凰架構(gòu)》里的一個計算方式：如果我們控制 BCrypt 的執(zhí)行時間大概是 0.1 秒完成一次哈希計算的話，按照 1 秒生成 10 個哈希值的速度，算完所有的 10 位大小寫字母（）和數(shù)字組成的弱密碼大概需要 P(62,10)/(3600×24×365)/0.1=1,237,204,169 年時間。

• P(62,10)是62取10的排列，這么多種密碼，62=26*2的大小寫字母+10個數(shù)字
• 3600×24×365，即 3600秒 x 24小時 x 365天

請注意，是 APP 端的 BCrypt 慢，但 APP 后臺的校驗并不慢，所以不會影響后臺服務(wù)性能。

最后，我們需要注意的是，雖然黑客已經(jīng)很難通過彩虹表來破解密碼了，但是仍然有可能暴力破解密碼，也就是對于同一個用戶名使用常見的密碼逐一嘗試登錄。因此，除了做好密碼哈希保存的工作外，我們還要建設(shè)一套完善的安全防御機制，在感知到暴力破解危害的時候，開啟短信驗證、圖形驗證碼、賬號暫時鎖定等防御機制來抵御暴力破解。

八. 掃碼登錄原理

在本文的最后一部分，我們來聊一下掃碼登錄的原理。回想一下，掃碼登錄是不是到處可見呢？那么，掃碼登錄的邏輯和流程是怎樣的呢？別著急，我們一起來看看這個有趣有用的問題。

用戶登錄APP后，會獲取登錄態(tài)票據(jù)(session key, 簡寫為skey)，在后續(xù)操作中，不必再輸入密碼，APP自動攜帶登錄態(tài)票據(jù)，此時APP后臺進(jìn)行登錄態(tài)票據(jù)校驗即可，提升了便利性。

用戶登錄APP后，獲取到了登錄態(tài)票據(jù)skey, ?然后用戶利用APP對網(wǎng)頁上的二維碼進(jìn)行掃描，獲取隱藏在二維碼中的token，并把token提交到后臺，下圖一目了然，無需具體解釋每一步。

值得注意的是，步驟6執(zhí)行完后，步驟3中的輪詢才會知道網(wǎng)頁token和APP端的userID/skey在后臺建立了關(guān)聯(lián)，此時掃碼登錄成功。我曾經(jīng)也設(shè)計了一個掃碼登錄方案，思路上大同小異。

好的，本文先聊到這里了，相信大家對注冊登錄中的安全問題有了更深入的理解。愿工作順利，面試也順利。今天先這樣，咱們明天見。