開發者工具 · UUID 產生器
隨機 UUID 作為密碼重設或會話令牌安全嗎？
· 為什麼它很重要
uuid 密碼學 瀏覽器 API
來自 CSPRNG 的 v4 UUID 具有大量熵，那麼為什麼安全審查者仍然對 UUID 令牌皺眉呢？這篇文章將熵問題與設計問題分開。
使用行的 UUID 的重置連結 - 一個常見的快捷方式以及它可能不安全的兩個截然不同的原因
常見捷徑：使用使用者的 UUID 行識別碼作為密碼重設令牌。表格有一個 uuid 列；它是獨一無二的；很難猜測（如果是 v4）。 URL 為 /reset? 令牌=550e8400-e29b-41d4-a716-446655440000。安全審查員立即拒絕它，不是因為 UUID 很弱，而是因為它結合了兩個應該獨立的問題。行 UUID 是穩定的且通常是公開可見的（在 URL、API、日誌中）。重置令牌應該是一次性且保密的。重複使用 UUID 行作為令牌意味著使用者的身分及其重置憑證具有相同的值，並憑證將永遠存在而不是過期。知道使用者 ID 的攻擊者可以執行重置。五年前複製貼上重置連結的用戶仍然可以使用它。這些是設計缺陷，而不是熵缺陷。
熵檢查：122 隨機位元 - 為什麼 CSPRNG 產生的 v4 無法透過暴力破解
隨機性檢查是必要的，但還不夠。版本 4 保留四個版本位和兩個變體位，當實現隨機填充其他欄位時，留下 128 - 4 - 2 = 122 隨機位置。該推導沒有提及過期、儲存或授權。產生器檢查詢問這些欄位是否來自 CSPRNG 而不是 Math.random 或時間戳記。 ToolAcre 滿足此產生器邊界。設計檢查仍然是特定於應用程式的：重置憑證需要單獨的生命週期、單向儲存表示、成功使用後失效以及從服務風險策略中選擇的到期時間。即使安全地產生了使用者的永久記錄 ID，重複使用該 ID 也無法實現分離。
產生器檢查：UUID 令牌實際上失敗的地方 — 基於 Math.random 的產生、v1 時間戳和 MAC 位址以及可預測的種子
一個可行的範例：密碼重設方案失敗，然後經過三項檢查。熵檢查失敗：伺服器透過 Math.random() 發出重置令牌，打包為 v4 UUID。攻擊者觀察三個令牌並預測第四個。產生器檢查失敗：伺服器使用 v1 UUID 作為重設令牌，包括值中的建立時間戳記和 MAC 位址。攻擊者讀取時間戳，了解何時發出重置，並縮小搜尋視窗。透過熵檢查，但未通過設計檢查：伺服器使用 crypto.getRandomValues 中的 v4 UUID，但將其以純文字形式儲存在資料庫中，並不設定過期時間。破壞資料庫的攻擊者會讀取重置令牌，並在幾週後使用它們重置帳戶。三項檢查是獨立的；你必須通過全部三項。
設計檢查：標識符與憑證 — 為什麼重用記錄的主鍵作為秘密結合了兩個應該獨立輪換的東西
透過熵和產生器檢查但未通過設計檢查（無雜湊、無到期、無每次使用失效）的重置令牌方案仍然容易受到攻擊。處理令牌伺服器端：當使用者要求重設密碼時，從 crypto.getRandomValues 產生新的隨機令牌（不是行 UUID）。儲存單向表示而不是呈現值，設定特定於策略的到期時間，並在成功使用後使記錄無效。當用戶點擊連結時，透過電子郵件尋找用戶，取得儲存的雜湊值，將提供的令牌與雜湊值進行比較，檢查過期情況，並僅在令牌有效且尚未過期時執行重置。立即使令牌失效（將其刪除或標記為已使用），使其無法重複使用。切勿記錄原始令牌；僅記錄使用者 ID 和操作。
處理令牌伺服器端 — 儲存雜湊值、設定到期日、使用時無效，且從不記錄原始值
令牌不應出現在錯誤訊息或資料庫中，除非經過雜湊處理。完整的身份驗證設計超出了 UUID 文章的範圍，但原則仍然成立：122 位元隨機令牌本質上並不是存取權杖。隨機性是比較容易的部分； ToolAcre 產生器為您提供 CSPRNG 支援的 UUID。困難的部分是設計：儲存前進行雜湊、設定過期時間、使用時失效、防止將永久 ID 重複用作臨時機密、審核誰存取了什麼以及何時存取。僅根據令牌的熵批准重置連結方案的安全審查員將跳過其餘的分析。如果開發人員認為 CSPRNG 支援的 UUID 足以用於密碼重置連結，而無需散列、過期和失效，那麼他低估了威脅。隨機性可以防止猜測；該設計可防止重播、過期和誤用。
工作範例 - 針對每次檢查檢查重設連結方案並重寫薄弱部分
ToolAcre 產生器正確處理了隨機性部分；應用程式必須正確完成設計部分。針對所有三個檢查測試您自己的重置連結程式碼：它是否使用 CSPRNG（crypto.getRandomValues、crypto.randomUUID 或加密庫），而不是 Math.random？令牌有有效期限嗎？令牌在存儲之前是否经過哈希處理？ token使用後會失效吗？代碼是否避免重複使用使用者的永久 ID 作為臨時令牌？如果您對所有這些問題的答案都是肯定的，那麼您的重置連結設計就是合理的。 ToolAcre產生器是CSPRNG部分；其餘的是您必須仔細檢查的應用程式程式碼。了解三個安全層有助於您審核第三方 UUID 庫和框架。當您評估庫時，請檢查它是否使用 CSPRNG（熵檢查），而不是弱隨機來源。檢查它是否記錄了它使用的來源以及原因（產生器檢查）。
這不包括什麼——完整的身份驗證設計、MFA 和速率限制，這些與令牌熵一樣重要
檢查範例程式碼和檔案是否強調設計原則：雜湊、過期、失效（設計檢查）。通過所有三項檢查的圖书馆很少见。大多數人只關注熵。 ToolAcre 產生器使用 crypto.getRandomValues 透過熵和產生器檢查。設計檢查是您的責任；圖書館無法知道您的過期要求或哈希策略。調試損壞的複位鏈路系統通常會發現三種故障之一。如果使用者報告收到不再有效的重置連結，則可能的問題是過期：令牌已頒發，但在使用者點擊連結之前已過期。如果令牌被多次重複使用，失效就會被打破。如果令牌出現在錯誤訊息或偵錯輸出中，則日誌記錄會洩漏它們。如果重置連結對一個使用者有效，但對另一個使用者無效，則可能存在資料庫複製延遲或過期計算時區問題。如果合法的重置請求隨機失敗，CSPRNG 可能會損壞（罕見）。
重點：隨機性是最簡單的部分 - ToolAcre 產生器為您提供 CSPRNG 支援的 UUID；剩下的就是設計紀律
從日誌記錄開始：啟用詳細的審核日誌以進行重置連結產生和驗證，然後重現問題並追蹤流程。 ToolAcre 產生器確保前兩項檢查通過；解決重置連結問題幾乎總是屬於設計類別。生產重置連結系統的最佳實踐包括：為每個重置請求產生新的隨機令牌，而不是重複使用舊令牌。將單向表示與帳戶和建立元資料一起存儲，然後從服務記錄的風險策略中選擇到期時間。驗證成功後立即使token失效。記錄重置請求和成功以供審核。實施速率限制以防止暴力攻擊。僅透過電子郵件發送重置連結，而不是短信或未加密的渠道。通知使用者密碼重設嘗試（以便他們可以偵測到未經授權的重設）。 ToolAcre 產生器為您提供隨機性；遵循這些做法可以為您帶來安全感。