[TOC] # 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不是純粹只使用時間，而是計算當前時間戳+隨機數+機器MAC地址得到，MAC地址具有唯一性，保障了UUID的唯一性，但是MAC地址可偽造，導致了UUID Version1存在安全問題。

UUID Version2：DCE安全的UUID

DCE（分散式計算環境）中的UUID和基於時間的UUID演算法相同，但是會把時間戳的前4位置換成POSIX的UID或GID。但是這個版本在現實生活中使用較少

UUID Version3：基於名字的UUID（MD5）

基於名字的UUID通過計算名字和名字空間的MD5雜湊值得到。這個版本保障了：相同名字 + 不同名字空間 => UUID的唯一性；不同名字空間的UUID的唯一性；相同名字 + 相同名字空間 => UUID重複生成是相同的

UUID Version4：隨機UUID

根據隨機數或者偽隨機數生成的UUID，但是存在缺陷，UUID產生重複的概率是可以計算出來的

UUID Version5：基於名字的UUID（SHA1）

和UUID Version3演算法類似，只是雜湊值用了SHA1演算法，SHA1在長度上比MD5長的多（SHA1：160位=40個16進位制字元，MD5：128位=32個16進位制字元），換算成冪指數的話相差就很大了，只能在一定程度上提高了通過“彩虹表”來破解的難度 （加鹽salt運算，無法逆向破解，可通過彩虹表形式對比） ## 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、書籍：《電腦保安原理與實