文章目錄
1、概述
本篇文章將對安全的隨機數與真/僞隨機數進行介紹，想必大家在編碼過程中，很少注意使用真隨機數或者安全的隨機數去生產隨機數，那麼爲什麼要用安全的隨機數呢？（廢話，因爲安全啊！！！）本篇文章將帶你探索未知的隨機數領域。
（想直接瞭解本文結論的同學，請直接跳轉 【4.4安全隨機數】 的章節）
2、名詞解釋
- 僞隨機數：通過數學算法+種子生成的隨機數，存在一定的規律，並非真的隨機數
- 弱僞隨機數：僞隨機數中的一種，易於預測的隨機數
- 強僞隨機數：僞隨機數中的一種，難以預測的隨機數
- 真隨機數：通過物理系統生成的隨機數，例如電壓波動、磁盤磁頭讀/寫時的尋道空間，電磁波噪聲、擲硬幣等
- 安全的隨機數：具有一定強壯的隨機數算法生成的隨機數，包括真隨機數和強僞隨機數
- 鹽值：通常在用戶註冊時，用來和用戶輸入的密碼進行組合的隨機數
- 散列函數（散列化）：就是我們通常說的Hash（哈希），把輸入的信息通過一定的散列算法生成了一種散列值的過程就是散列化，散列函數就提供了散列算法，例如SHA
- RSA：一種非對稱加密算法
- UUID：通用唯一識別碼，128位
- DCE：分佈式計算環境
- SHA1：安全散列算法
- 彩虹表：用於加密散列函數逆運算而進行預先計算的表，針對於破解密碼的散列值而出現的
3、隨機數存在的安全風險
3.1 弱僞隨機數帶來的安全風險
剛當上程序員的小新人，遇到隨機數的使用場景，一般都會調用Random這樣的函數，通過srand(time())這樣的形式給rand函數添加隨機種子，產生隨機數（有的隨機數發生器默認就是用時間作爲隨機種子，例如JAVA的java.util.Random）。這樣的隨機數只適合用於遊戲、抽獎等場景，而不適用於加密、密鑰生成等重要操作場景
舉個例子：通過郵箱重置密碼的操作是很常見的，但是如果進行了不安全的設計和編碼，則容易引發安全風險，例如重置密碼時，用戶ID和當前的時間戳綁定，而該時間戳作爲種子用於加密密碼。
URI：https://www.xxx.com/password/find
Method：PUT
Param：[email protected]
seed=5512AADBF06182F1FEC988114385557E
將【seed】字段解密後，時一個時間戳：1607993226。因爲一般系統時間跟着標準時間同步，所以時間戳時可預測的，當匹配到了該時間戳，那麼就成了一個攻擊者的突破口
3.2 真隨機數真的安全嗎
計算機安全領域沒有絕對的安全，只有相對的安全（除非你不編碼，不想當個程序猿）
相對比於其他隨機數，真隨機數的產生條件較爲苛刻，通過獲取物理條件產生，電壓波動、磁盤讀寫的尋道空間等，難以被利用，當然，存在着撞庫的風險，概率極低，破解的成本巨大。如果你使用了真隨機數，仍然有攻擊者想修改你的密碼，獲取信息，那就恭喜你了，說明在攻擊者眼裏，你可是個富翁（沒有利益驅動，攻擊者將對你毫無興趣）
4、隨機數
4.1 什麼情況下才使用隨機數
這時候你心中定有疑惑，隨機數能幹嘛？（一般來自新手的疑問，老司機還有這個疑惑那就unbelievable）
隨機數常常與密碼算法、ID、區塊鏈聯繫在一起，再具體一點例如福利彩票、門禁藍牙隨機密碼、抽獎
舉幾個例子：
密碼學上使用的鹽值、密鑰等使用隨機的條件，加強密碼保存或傳輸的安全性；
UUID使用隨機的方法保障ID唯一性，並可以在UUID的基礎上，複用UUID拓展更多的功能，例如截取部分UUID作爲虛擬機ID、使用UUID生成具有唯一性的存儲ID和用戶ID；
區塊鏈中使用私鑰加密貨幣，私鑰的產生用的就是隨機數；POS隨機記賬人場景（爲了公平的分配記賬券）
隨機數的使用生活中處處可見，進行高危操作，例如加密場景，要使用安全的隨機數
4.2 僞隨機數
Q1：爲什麼會有“僞隨機數”這個名詞？
A1：隨機數中的“隨機”體現出不可預測性，沒有規律可言，而人爲的，通過一定算法生成的隨機數，存在一定規律性，並不真正隨機，所以稱爲“僞隨機數”
Q2：僞隨機數的由來
A2：起源於20世紀早期科學工作，研究人員通過物理方法採集隨機數，但是通過物理方法採集的“真隨機數”十分低效，實時獲取隨機數的速度緩慢，保存隨機數額外佔用存儲空間等缺點，便開始尋求“僞隨機數”的方法，來解決效率等問題
Q3：僞隨機數目前分爲幾類？
A3：僞隨機數根據預測性的難易程度，分爲弱僞隨機數（易預測）和強僞隨機數（難預測）。
4.2.1 弱僞隨機數
Q1：什麼是弱僞隨機數？
A1：顧名思義，這種的類型的隨機數只是爲了滿足隨機性，但是可以預測。舉個例子，Java編程語言Random函數，就是基於時間作爲種子，去構造隨機數，假如攻擊者獲取了該時間，那麼就可以預測下一個隨機數的結果。
Q2：常見的弱僞隨機數有哪些？
A2：以下是容易產生弱僞隨機數的函數，取決於隨機“種子”、隨機範圍、隨機數的對象的選擇
| 編程語言 | 弱僞隨機數 | 備註 |
|---|---|---|
| C/C++ | srand( time() ) + rand() | 以時間爲種子，產生隨機數 |
| C# | Random() System.Guid() |
|
| Perl | srand( time() ) + rand() | 以時間爲種子，產生隨機數 |
| Python | import numpy rng = numpy.random.RandomState( time() ) array_rand_num = rng.uniform() --------------------------- import random random.seed() |
|
| Ruby | srand( time() ) + rand() | 以時間爲種子，產生隨機數 |
| JAVA | Random |
|
| PHP | srand() + rand() mtstrand() + mtrand() |
安全建議：涉及到加密、CSRF Token等重要操作時
- 不要使用時間函數作爲種子或者隨機數：time()/microtime()
- 不要使用rand這樣的弱僞隨機數生成器
- 隨機數的長度要足夠長
4.2.2 強僞隨機數
Q1：什麼是強僞隨機數？
A1：指難以預測的僞隨機數，通常用於密碼學中，例如JAVA中的java.security.SecureRandom函數，其用於隨機的種子是不可預測的，比如鼠標點擊、鍵盤點擊等物理條件
4.3 真隨機數
Q1：Linux上可靠的真隨機數生成方法有哪些？
A1：比較可靠的方法是讀取/dev/random或者讀取/dev/urandom（在一定程度上，/dev/urandom是強僞隨機數）。
Q2：/dev/random和/dev/urandom有什麼區別？
A2：
- 首先，Linux環境下是根據系統的熵值來產生隨機數，熵的來源是環境噪音，噪音的來源是鍵盤輸入、鼠標移動、內存的使用、進程數等。
- 其次，/dev/random是真隨機數生成器，通過消耗熵值來產生隨機數、同時熵耗盡的情況下會造成阻塞，直到有心的熵的生成。而/dev/urandom是強僞隨機數生成器，它根據初始的隨機種子（熵），來產生隨機數，但是不會消耗掉熵，不會再熵消耗完的情況下阻塞。
- 這時候就有個問題了，如果系統啓動階段使用了/dev/urandom，而這時沒有任何的熵，那麼這時候使用的是內置的種子，產生隨機數還是存在可預測性的
- 最後，仍然建議使用 /dev/urandom，在計算機安全領域，沒有絕對的安全，只有相對的安全（除非你不編碼、不開發、不做禿頂的程序猿）
4.4 安全隨機數
隨機數涉及到加密等重要操作場景，推薦使用以下安全隨機數
| 編程語言 | 安全隨機數 | 備註 |
|---|---|---|
| C/C++ | CryptGenRandom（Windows） | 原理：依據當前進程ID、當前線程ID、當前時間、用戶名、計算機名、CPU計數器等，生成隨機數，和/dev/random一樣，效率低，消耗資源大 |
| .NET(C#) | System.Security.Cryptography.RNGCryptoServiceProvider | 原理：和CryptGenRandom（Windows）類似 |
| Perl | Math::Random::Secure | 原理：所使用的種子種類繁多，且是隨機使用的，攻擊者可能要費勁10多年才能遍歷完成 |
| Python | os.urandomrandom.SystemRandom() | 原理：函數返回的隨機字節，是操作系統所帶的隨機函數產生，具有特異性這裏"urandom"裏"u"應該指的是"unexpected"–難以預料 |
| Ruby | Sysrandom(取代SecureRandom） | 適用於生成session token原理：使用/dev/urandom |
| JAVA | java.security.SecureRandom | 原理：提供加密強度高的隨機數生成器，默認條件下（不傳其他種子的話，默認種子來源是/dev/random，但是存在熵耗盡導致阻塞的現象），就可以產生安全的隨機數；解決熵值耗盡的方法要不就是不斷增加熵值，要不就種子來源換成/dev/urandom |
| PHP | mcrypt_create_iv, openssl_random_pseudo_bytes，random_bytes，random_int | 原理：random_bytes/random_int – 不同系統上，源頭不同，Windows上使用CryptGenRandom，Linux上使用getrandom(2)或/dev/urandom |
| GNU/Linux或Unix | 讀取/dev/random or /dev/urandom | 4.3講的很清楚了 |
5、拓展場景
5.1* 密文密碼中的鹽值（拓展）
上圖是Linux常用的密碼生成與密碼驗證的原理圖，
- a）生成密文密碼：輸入明文密碼+系統產生的鹽值 =>（散列化） 密文密碼
- b）驗證密碼：輸入明文密碼+用戶ID +存儲的鹽值 =>（散列化）密文密碼，生成的密文密碼與存儲的密文密碼比對
很明顯，加入鹽值的目的如下：
- 1、防止使用的密碼存儲時以明文形式存儲。即使兩個不同的用戶使用相同的明文密碼，但是使用了不同的鹽值之後，最後的密文密碼便是不同的。
- 2、顯著增加密碼破解的難度。例如一個長度爲128位的鹽值，可能產生的密文密碼數量會是2的128次方個，加大密碼猜測的難度。
- 3、讓攻擊者難以發現同一個用戶在不同的操作系統上使用相同的密碼
安全建議如下：
- 存儲密碼時要以密文密碼存儲，而不是使用明文密碼存儲
- 如果只時爲了校驗密碼的目的而去使用密碼（無論是校驗自身平臺還是第三方平臺），那麼使用密碼+鹽值再進行散列化後的結果形式進行存儲，這樣比較安全（因爲散列化不可逆），進而進行比較時用的時密文密碼比較，而非明文密碼比較，減少了解密時候帶來的安全風險
- 如果存儲的密碼是爲了解密後使用，那麼通常的安全建議做法是，對密碼進行非對稱加密存儲，私鑰要進行分段加密存儲
- 使用的鹽值長度建議爲128位，極大提高攻擊難度
5.2* UUID的生成（拓展）
UUID是如何保持唯一性的呢？這裏將講述UUID經歷的5個版本。
| UUID Version1：基於時間的UUID |
| UUID Version2：DCE安全的UUID |
| UUID Version3：基於名字的UUID（MD5） |
| UUID Version4：隨機UUID |
| UUID Version5：基於名字的UUID（SHA1） |
5.3* 驗證碼的生成（拓展）
驗證碼的目的，是爲了區分操作者是計算機還是正常的人類，防止計算機暴力破解（計算機很笨，只會按照程序猿設定的方式進行，無法對自動生成的問題進行解答）
驗證碼形式：數字校驗、圖片校驗、拼圖校驗、語音校驗，這些校驗大同小異，無非是對數據進行校驗
舉個例子：
-
不安全的驗證碼傳輸：
爲什麼說它不安全呢？上圖是將驗證碼後續的操作判斷交給了前端，由前端去控制下一步操作，這樣做有什麼風險呢？
舉個例子：保存重要配置操作（驗證碼的目的就是用於校驗某次操作的安全性），在點擊保存配置的按鈕後，前端彈出驗證碼輸入框，用戶輸入完驗證碼後，點擊確定，這時候交給服務器識別驗證碼的正確性，然後返回flag=0或flag=1告知前端驗證碼校驗失敗或成功，由前端去決定是否調用這次保存配置的API。如果在第6步流程，當驗證失敗，flag=0，返回的響應信息被截取，將flag修改成1（數據僞造，驗證成功），那麼這次保存配置的操作將會成功。
安全建議：不要把一切操作都交給前端，特別時敏感操作；建議同步傳輸，在確認下發API的同時帶上驗證碼數據，由服務器統一處理。
【參考資料】
1、博客：《聊一聊隨機數安全》：https://blog.csdn.net/renwotao2009/article/details/51643799
2、博客：《C#生成隨機數的三種方法》：https://www.cnblogs.com/xiaowie/p/8759837.html
3、書籍：《白帽子講Web安全》
4、書籍：《計算機安全原理與實踐》