iT邦幫忙

2023 iThome 鐵人賽

DAY 8
0
自我挑戰組

前端工程師在 Qiita 閱讀的雜食筆記系列 第 8

Day8 - 鹽加密的鹽通常會存放在哪裡

  • 分享至 

  • xImage
  •  

原文連結:ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita


對於 pictBLand 和 pictSQUARE 受到非法訪問,且將密碼儲存在未加鹽的 MD5 Hash 中的事件,近來已成話題。

2023 年 8 月 16 日,有篇投稿聲稱持有從 pictSQUARE 竊取的數據,並將這些資料銷售給外部論壇(部分略)。該投稿指出,雖然密碼已進行 MD5 HASH,由於未進行加鹽,因此已取得 29 萬 4512 組簡單密碼的原始字串(剩餘 26 萬 8172 組仍保持 MD5 HASH 值)。
內容引用自 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog

在這段期間,觀察有關 MD5 HASH 和 salt 的推文(post),似乎有許多人對 salt 的理解是錯誤的。因此,我提出了以下的「測試問題」。收到許多回答對此十分感謝。

【問題】在儲存密碼 HASH 值時,通常會將鹽存放在哪裡呢?
(1) 將鹽儲存在高度機密的文件中,並透過環境變數傳遞
(2) 與 HASH 值一起存放在資料庫中
(3) 儲存在硬體安全模組(HSM)中
(4) 不進行儲存,每次都生成隨機的鹽
原推文連結

正確答案是「與 HASH 值一起存放在資料庫中」,結果發現正確率非常低,只有 33.9%。我的「擔憂」似乎已成現實。

那麼,讓我們來檢討答案吧。

使用 HASH 值保存密碼的原因

首先來談談,使用 HASH 值保存密碼的目的:

  • 即使密碼訊息外洩,仍希望盡量延遲密碼的濫用
  • 即使是管理員,若知道用戶的密碼也會提高被濫用的可能性
  • 若伺服器遭受入侵,加密密鑰也可能會被竊取

基於上述理由,通常會以 HASH 值保存密碼,而非採用可解密的加密密鑰管理。如同 Unix/Linux/Windows 等系統,也是將用戶的密碼以 HASH 值的形式保存,網頁應用程序也會要求避免以明碼形式,而是使用 HASH 值保存。

加鹽的目的

  • 若僅使用單純的 HASH 值,那麼設定相同密碼的用戶之間,其 HASH 值也會相同,這種情況將會提高風險
  • 透過彩虹表等方法,對於約 8 個字符的英數字密碼,可在幾秒~幾分鐘內還原成明碼,因此加鹽是為了使「看起來的密碼長度」更長

下圖是以 SHA-256 保存密碼的範例,顯示設定相同密碼「password」的用戶,其 HASH 值將完全一致的情況。一旦被發現擁有相同密碼,將成為非法登錄的途徑。即使計算雜湊公式(Hash Function)為未知,一旦被發現「擁有相同的密碼,很有可能是簡單的密碼」,並且攻擊者能夠遠程進行字典攻擊,或是透過故意註冊簡單的密碼,從而一網打盡這些用戶的密碼。

為了避免這種情況,通常會生成一個稱為鹽的短字串,並附加到密碼的前後來計算 HASH 值。由於每個使用者的鹽都不同,即使是密碼相同,也會產生不同的 HASH 值。

鹽通常會存放在哪

如上文所述,即使在 Unix 中,也曾使用 HASH 值儲存密碼,但由於每個系統和版本會有不同的 HASH 值儲存格式,因此存在互通性問題。為了解決這個問題,設計出 Modular Crypt Format(MCF,模組加密格式),並廣泛應用於現今的 Linux 等系統(參考)。以下是以鹽 = SALT(實際是用隨機字串),密碼 = pokemon,以 SHA-512 格式計算密碼 HASH 值的結果:

$ openssl passwd -6 -salt=SALT pokemon
$6$SALT$ULXzhDaWogf6Q3KHTtpYdqKKEIaFPML8gl5wpHpvPJVkGgiKGubqkogwvqoVn3eDsrJuRB22w.RPWzAdEu1xD.

這是 Linux 的 /etc/shadow 儲存密碼 HASH 值的格式。上方內容有以下含義:

$6$  雜湊方式(在這個範例是用 SHA-512)
SALT 鹽(在實際操作中使用隨機字串)
ULX..以下是 HASH 值

HASH 值、鹽和雜湊方式會「一起」儲存在文件的一行中。由於密碼驗證需要這些訊息,因此會需要儲存在一起。

MCF 最初是為 Unix/Linux 的密碼儲存而設計的,但目前在 Web 應用程式中也被廣泛使用於需要儲存密碼的情況。以下是使用 PHP 的 password_hash 函數,將密碼 = pokemon 轉換的範例:

$ php -r "echo password_hash('pokemon', PASSWORD_DEFAULT), PHP_EOL;"
$2y$10$5MLO1PPVHzUiW/mggn8kAOkF/aoRk0RaLBSH3CwU47jmacYoGtrFa

上述範例代表的涵意如下:

2y algorithm=bcrypt
10 Steching 次數的指標(不代表 10 次)
5MLO1PPVHzUiW/mggn8kAO Salt
kF/aoRk0RaLBSH3CwU47jmacYoGtrFa HASH 值

不只是 PHP,主要的 Library 和 Framework 都使用 MCF 格式,應用程序通常會將密碼資訊以 MCF 格式儲存在資料庫中。

因此,對於上述問題的解答是(鹽)「應該與 HASH 值一起保存在資料庫中」。透過使用MCF,即可在 PHP 開發的 Web 應用程式移植到 Ruby on Rails 等框架的情況,仍保持同樣的密碼資訊直接移植。

若 HASH 值和鹽一起儲存,是否會在洩露時被濫用?

這裡許多人會抱持著疑問,若把 HASH 值和鹽一起儲存,那麼密碼在洩露後是否會輕易被破解?

確實「若花費足夠的時間,是可以被破解的」,但這並不容易。由於雜湊函數是單向的,因此無法從 HASH 值和鹽,透過數學公式等方式計算出明文密碼,而需使用字典攻擊或暴力破解。在儲存密碼時,應使用避免使用常見的高速雜湊函數(如 MD5 或 SHA-2),而是為密碼保護而設計出「緩慢的」算法,如 bcrypt、scrypt、Argon2 等。除了改良算法,還包括重複進行雜湊計算的延伸步驟(Stretching,Linux 用來保存密碼的 $6$ 格式也有執行延伸)。透過這些措施,能夠使密碼的 HASH 值在短時間內無法被濫用,為密碼變更提供緩衝時間。

另一方面,若原始密碼本身就很簡單,像是 password 或 123456 等,容易被字典攻擊破解。這是使用 HASH 值儲存密碼時的限制,為了解決這個問題,開始出現了所謂的胡椒(pepper)。pepper 是一個單一的秘密字串,通過與密碼進行混合,可提升密碼的機密性。pepper 若是外洩,那將失去其意義,因此建議將 pepper 儲存在具高度機密性的硬體安全模組(HSM)等儲存設備中。”

錯誤的答案有何問題

以下是有關錯誤答案的重點解釋:

將鹽儲存在高度機密的文件中,並透過環境變數傳遞

這種實作方式無法滿足鹽的要求,因為必須達到「每個使用者都不同」。雖然這種方法可能適用於 pepper,但若以可能被入侵為前提,透過環境變數傳遞並不安全。

儲存在硬體安全模組(HSM)

這種實作也難以滿足「每個使用者都不同」的需求,特別是考慮到使用者數量可能超過數十萬的情況。另一方面,這種方法更適用於儲存 pepper。但如果已經選擇使用 HSM,就不應該把加密金鑰移出 HSM,而是善用 HSM 的特性,直接在內部加密密碼 HASH 值。

不進行儲存,每次都生成隨機的鹽

雖然可以在每次都生成隨機的鹽,但若不儲存鹽,將無法進行密碼驗證。

總結

本文首先以問答形式,提出有關如何儲存鹽的問題,並進行了解說。目前主流儲存鹽的方法,是透過 Modular Crypt Format(MCF),被廣泛使用於 Linux 和 Web 應用程式的密碼儲存。但即使不知道這一點,只要使用高安全性的密碼儲存 Library,也非常有機會在未知的部分使用到 MCF 格式。
通常情況下,鹽會和 HASH 一起儲存,如前文所述,但如果不放心,則可以考慮使用 pepper(有時稱作 Secret Salt)。在這種情況下,如何安全管理 pepper 將是一項挑戰,例如考慮使用 HSM 或 Cloud HSM 作為選項。

宣傳

更多內容可參考作者的 YouTube 頻道,提供許多有關密碼保護的影片說明。

Yes

エッセンシャルコース詳細 | Security Campus


上一篇
Day7 - 為什麼軟體必須要版本升級
下一篇
Day9 - 有魅力的 Repository 會如何撰寫 README.md
系列文
前端工程師在 Qiita 閱讀的雜食筆記31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
nihilitypeo
iT邦新手 4 級 ‧ 2023-10-29 22:41:57

謝謝分享,我之前一直不懂為什麼要一起存放,現在懂了!!

我要留言

立即登入留言