為什么寫(xiě)這篇文章

近期，Github被爆出，在內(nèi)部日志中記錄了明文密碼。

雖然據(jù)說(shuō)影響面很?。ㄒ?yàn)槿罩就獠吭L問(wèn)不到），但是網(wǎng)絡(luò)和數(shù)據(jù)安全問(wèn)題又一次被放到臺(tái)面上。大多數(shù)用戶(hù)的常用密碼就那么幾個(gè)，一旦被黑客拿到，去其他網(wǎng)站“撞庫(kù)”，可能會(huì)造成用戶(hù)的財(cái)產(chǎn)損失。

本篇文章主要介紹如何加密傳輸和存儲(chǔ)用戶(hù)密碼，并講解相關(guān)原理。

[[230936]]

加密傳輸

加密主要有兩種方式：對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密。

對(duì)稱(chēng)加密

對(duì)稱(chēng)加密算法在加密和解密時(shí)使用的是同一個(gè)秘鑰。

對(duì)稱(chēng)加密的模式是：

- 甲方選擇某一種加密規(guī)則，對(duì)信息進(jìn)行加密

- 乙方使用同一種規(guī)則，對(duì)信息進(jìn)行解密

客戶(hù)端和服務(wù)端進(jìn)行通信，采用對(duì)稱(chēng)加密，如果只使用一個(gè)秘鑰，很容易破解；如果每次用不同的秘鑰，海量秘鑰的管理和傳輸成本又會(huì)比較高。

非對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密算法需要兩個(gè)密鑰來(lái)進(jìn)行加密和解密，這兩個(gè)秘鑰是公開(kāi)密鑰（public key，簡(jiǎn)稱(chēng)公鑰）和私有密鑰（private key，簡(jiǎn)稱(chēng)私鑰）。

非對(duì)稱(chēng)加密的模式則是：

- 乙方生成兩把密鑰（公鑰和私鑰）。公鑰是公開(kāi)的，任何人都可以獲得，私鑰則是保密的

- 甲方獲取乙方的公鑰，然后用它對(duì)信息加密

- 乙方得到加密后的信息，用私鑰解密。

即使黑客拿到了公鑰，沒(méi)有私鑰也是沒(méi)有辦法解密，不考慮彩虹表的情況，完全可以長(zhǎng)期使用一對(duì)秘鑰。

RSA算法

最經(jīng)典的非對(duì)稱(chēng)加密算法是RSA算法。

RSA公鑰加密算法是1977年由羅納德·李維斯特（Ron Rivest）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一起提出的。公鑰私鑰成對(duì)出現(xiàn)，用其中一個(gè)加密只能用另一個(gè)解密，通常用公鑰加密私鑰解密。

為什么RSA能夠做到非對(duì)稱(chēng)加密呢？

互質(zhì)關(guān)系：如果兩個(gè)正整數(shù)，除了1以外，沒(méi)有其他公因子，我們就稱(chēng)這兩個(gè)數(shù)是互質(zhì)關(guān)系

簡(jiǎn)單來(lái)說(shuō)，RSA利用的原理是，如果兩個(gè)互質(zhì)關(guān)系的正整數(shù)的乘積足夠大，是極難進(jìn)行因式分解的（目前被破解的最長(zhǎng)RSA密鑰是768個(gè)二進(jìn)制位，而正常使用的至少是1024位的密鑰）。

通過(guò)一定的運(yùn)算，把某計(jì)算結(jié)果和乘積作為公鑰，另一個(gè)計(jì)算結(jié)果和乘積作為私鑰，即可以實(shí)現(xiàn)，利用公鑰進(jìn)行加密，并利用私鑰進(jìn)行解密。具體的數(shù)學(xué)公式推導(dǎo)和證明可以參考RSA算法原理。

github的登錄方式

傳輸層面的加密解密原理講的差不多了，我們來(lái)看看github是如何傳輸賬號(hào)密碼的。

抓包看一下登錄請(qǐng)求的request，赫然發(fā)現(xiàn)，密碼是通過(guò)明文傳輸?shù)?hellip;…

那么，這種傳輸方式安全嘛？還可以，因?yàn)槭褂昧薶ttps，但還不夠安全。

http和https

常規(guī)的http請(qǐng)求，所有信息明文傳播，只要中間人在鏈路中的任意階段進(jìn)行劫持，就會(huì)帶來(lái)三大風(fēng)險(xiǎn)：

• 竊聽(tīng)風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。
• 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。
• 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。

怎么解決這些問(wèn)題？用https。

https 可以認(rèn)為是 http + TLS，TLS 是傳輸層加密協(xié)議，它的前身是 SSL 協(xié)議。

SSL/TLS協(xié)議是為了解決http的三大風(fēng)險(xiǎn)而設(shè)計(jì)的，希望達(dá)到：

- 內(nèi)容加密。所有信息都是加密傳播，第三方無(wú)法竊聽(tīng)。

- 身份認(rèn)證。配備身份證書(shū)，防止身份被冒充。即使被 DNS 劫持到了第三方站點(diǎn)，也會(huì)提醒用戶(hù)有可能被劫持

- 數(shù)據(jù)完整性。防止內(nèi)容被第三方冒充或者篡改。具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。

說(shuō)了這么多，https到底做了什么？結(jié)合以下流程圖，講解一次https請(qǐng)求都發(fā)生了什么：

1、客戶(hù)端發(fā)起https請(qǐng)求

2、服務(wù)端的配置

一般需要向權(quán)威機(jī)構(gòu)申請(qǐng)一個(gè)證書(shū)（也可以自己制作，這個(gè)會(huì)在之后的中間人攻擊中講到，區(qū)別就是自己頒發(fā)的證書(shū)需要客戶(hù)端驗(yàn)證通過(guò)，才可以繼續(xù)訪問(wèn)，而使用受信任的公司申請(qǐng)的證書(shū)則不會(huì)提示），證書(shū)會(huì)生成RSA加密使用的一對(duì)公鑰A和私鑰B。

3、傳送證書(shū)

這個(gè)證書(shū)主要內(nèi)容是公鑰A，也包含了其他信息，如證書(shū)的頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等。

4、客戶(hù)端解析證書(shū)

由客戶(hù)端的TLS來(lái)完成的，主要是驗(yàn)證公鑰A是否有效，比如頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書(shū)存在問(wèn)題。如果證書(shū)沒(méi)有問(wèn)題，那么就生成一個(gè)隨機(jī)值。之后就進(jìn)入了不對(duì)稱(chēng)加密（RSA）的過(guò)程，用證書(shū)對(duì)該隨機(jī)值進(jìn)行加密，生成私鑰C。

5、傳送加密信息

這部分傳送的是用證書(shū)加密后的隨機(jī)值（即私鑰C），目的就是讓服務(wù)端得到這個(gè)私鑰，后續(xù)所有的數(shù)據(jù)都可以用私鑰C，進(jìn)行對(duì)稱(chēng)加密和解密。

6、服務(wù)端解密信息

服務(wù)端用私鑰B解密后，得到了客戶(hù)端傳過(guò)來(lái)的私鑰C，到此RSA非對(duì)稱(chēng)加密的過(guò)程結(jié)束了。

7、傳輸加密后的信息

服務(wù)端用私鑰C加密信息。

8、客戶(hù)端解密信息

客戶(hù)端用之前生成的私鑰C解密服務(wù)端傳過(guò)來(lái)的信息，于是獲取了解密后的內(nèi)容。

中間人攻擊（MITM）

上面的過(guò)程，看起來(lái)似乎無(wú)懈可擊？并不是，因?yàn)?ldquo;人”才是安全系統(tǒng)中最脆弱的環(huán)節(jié)。

https信息的安全，完全建立在證書(shū)可信的基礎(chǔ)上，如果中間人偽造證書(shū)怎么辦？

黑客自己偽造的證書(shū)需要客戶(hù)端驗(yàn)證通過(guò)，才可以繼續(xù)訪問(wèn)，只要客戶(hù)端驗(yàn)證通過(guò)，那么公鑰A，私鑰B和私鑰C對(duì)黑客來(lái)說(shuō)都是透明的，也有沒(méi)有數(shù)據(jù)安全可言了，所以黑客只要誘導(dǎo)用戶(hù)安裝自己偽造的證書(shū)即可，例如使用各種釣魚(yú)的不可描述網(wǎng)站。

所以即使使用https傳輸明文密碼，也不是絕對(duì)安全的。那怎么樣才能保證密碼安全呢？

百度的登錄方式

抓包看一下百度的登錄請(qǐng)求發(fā)現(xiàn)，密碼是加密過(guò)的：

怎么加密的？我們發(fā)現(xiàn)，有這么一個(gè)關(guān)鍵請(qǐng)求：

response里有pubkey，意味著，密碼使用RSA進(jìn)行加密和解密處理的，這個(gè)請(qǐng)求傳輸?shù)氖枪€。那么流程是什么樣的呢？

查了一下github中，關(guān)鍵詞RSA，star數(shù)最多的JavaScript庫(kù)jsencrypt，驚喜的發(fā)現(xiàn)，百度登錄的加密方式和使用的函數(shù)名都和這個(gè)庫(kù)一致，那我們是不是可以大膽假設(shè)百度整套登錄請(qǐng)求時(shí)的流程和這個(gè)開(kāi)源庫(kù)基本一致呢，那jsencrypt的流程又是什么樣的呢，如下圖：

加密存儲(chǔ)

到這里，加密傳輸?shù)倪^(guò)程已經(jīng)完結(jié)了，現(xiàn)在服務(wù)端已經(jīng)收到了用戶(hù)真實(shí)的密碼（解密后的），那怎么存儲(chǔ)這個(gè)密碼呢？

千萬(wàn)不要用明文存儲(chǔ)密碼

如果用明文存儲(chǔ)密碼（不管是存在數(shù)據(jù)庫(kù)還是日志中），一旦數(shù)據(jù)泄露，所有用戶(hù)的密碼就毫無(wú)保留地暴露在黑客的面前，開(kāi)頭提到的風(fēng)險(xiǎn)就可能發(fā)生，那我們費(fèi)半天勁加密傳輸密碼也失去了意義。

用哈希算法加密密碼

單向加密算法：只能從明文生成一個(gè)對(duì)應(yīng)的哈希值，不能反過(guò)來(lái)根據(jù)哈希值得到對(duì)應(yīng)的明文。

常用的給密碼加密的算法是幾種單向的哈希算法。

經(jīng)常被大家用來(lái)加密的算法有MD5和SHA系列（如SHA1、SHA256、SHA384、SHA512等）。

雖然用哈希算法能提高密碼存儲(chǔ)的安全性，但還是不夠安全。

通常黑客在侵入保存密碼的數(shù)據(jù)庫(kù)之后，他會(huì)隨機(jī)猜測(cè)一個(gè)密碼，生成一個(gè)哈希值。如果該哈希值在數(shù)據(jù)庫(kù)中存在，那么他就猜對(duì)了一個(gè)用戶(hù)的密碼。如果沒(méi)有猜中也沒(méi)有關(guān)系，他可以再次隨機(jī)猜測(cè)下一個(gè)密碼進(jìn)行嘗試。

事實(shí)上黑客為了提高破解密碼的效率，他們會(huì)事先計(jì)算大量密碼對(duì)應(yīng)的各種哈希算法的哈希值，并把密碼及對(duì)應(yīng)的哈希值存入一個(gè)表格中（這種表格通常被稱(chēng)為彩虹表），在破解密碼時(shí)只需要到事先準(zhǔn)備的彩虹表里匹配即可。因此現(xiàn)在黑客們破解僅僅只用哈希算法加密過(guò)的密碼事實(shí)上已是不費(fèi)吹灰之力。

加“鹽”提高安全性

鹽：一個(gè)隨機(jī)的字符串，往明文密碼里加鹽就是把明文密碼和一個(gè)隨機(jī)的字符串拼接在一起。

為了應(yīng)對(duì)黑客們用彩虹表破解密碼，我們可以先往明文密碼加鹽，然后再對(duì)加鹽之后的密碼用哈希算法加密。由于鹽在密碼校驗(yàn)的時(shí)候還要用到，因此通常鹽和密碼的哈希值是存儲(chǔ)在一起的。

采用加鹽的哈希算法對(duì)密碼加密，要確保要往每個(gè)密碼里添加隨機(jī)的唯一的鹽，而不是讓所有密碼共享一樣的鹽。

雖然加鹽的算法能有效應(yīng)對(duì)彩虹表的破解法，但它的安全級(jí)別并不高，因?yàn)橛?jì)算哈希值耗時(shí)極短，黑客仍然可以用窮舉法來(lái)破解，只是增加了一些耗時(shí)。

用BCrypt或者PBKDF2增加破解的難度

為了應(yīng)對(duì)暴力破解法，我們需要非常耗時(shí)的而不是非常高效的哈希算法。BCrypt和PBKDF2算法應(yīng)運(yùn)而生。

這兩個(gè)算法最大的特點(diǎn)是我們可以通過(guò)參數(shù)設(shè)置重復(fù)計(jì)算的次數(shù)，重復(fù)計(jì)算的次數(shù)越多耗時(shí)越長(zhǎng)。如果計(jì)算一個(gè)哈希值需要耗時(shí)1秒甚至更多，那么黑客們采用暴利法破解密碼將幾乎不再可能。破解一個(gè)6位純數(shù)字密碼需要耗時(shí)11.5天，更不要說(shuō)高安全級(jí)別的密碼了。

總結(jié)

如果我們想要盡可能保證用戶(hù)的信息安全，我們需要做以下的工作

- 使用https請(qǐng)求

- 利用RSA加密密碼并傳輸數(shù)據(jù)

- 用BCrypt或者PBKDF2單向加密，并存儲(chǔ)