Shiny

淺談敏感資料的儲存

August 07, 2019 #bcrypt

敏感資料的儲存一直以來都是個問題,儲存的資料又分為只需要驗證是否一致(hash)或是需要可以反解回來(crypto),前者對應的通常是使用者的密碼,只需要驗證輸入是否一致即可。後者比較像是使用者的身分證字號或是信用卡卡號之類的。

關於密碼,以前常見的儲存方式會是使用雜湊來儲存,譬如說:

SHA1(password) = hash

透過這樣的方式儲存,可以在不知道使用者的密碼的情況下驗證密碼的正確性,假設資料庫儲存的密碼真的洩漏出去了,也沒辦法反推原始的密碼,感覺起來很完美!

但是如果你看到 7c222fb2927d828af22f592134e8932480637c0d 然後再去 Google 搜尋,你就會發現他其實是 12345678 的 SHA1 結果

SHA1(12345678) = 7c222fb2927d828af22f592134e8932480637c0d

為了避免這個問題,後來就推出了新的金鑰雜湊訊息鑑別碼(HMAC)的方式,透過一把私鑰(key)混入雜湊讓同樣的密碼會產生出不一樣的 hash 值

HMAC(password, key) = hash

在私鑰(key)沒有被揭露的前提下,提高了破解的難度,但是如果私鑰也被洩漏了的話,保護效果就沒有想像中的好了。

現在很安全的 SHA512 可能過幾年就因為電腦計算能力的增強而變得不安全了(暴力破解),為了因應這個情況,後來有人提出了 bcrypt 的加密方式來解決這問題

bcrypt 可以調整 cost 並且每次都有隨機的 salt,讓同樣的密碼產生出不同的結果

source: [https://stackoverflow.com/questions/27592732/what-should-be-stored-in-table-while-using-bcrypt](https://stackoverflow.com/questions/27592732/what-should-be-stored-in-table-while-using-bcrypt)source: https://stackoverflow.com/questions/27592732/what-should-be-stored-in-table-while-using-bcrypt

當然不只 bcrypt 可以做到,目前還有 PBKDF2 與 Scrypt 可以達到相似的效果,因為是淺談,所以就不深入了。

From the scrypt paper: estimated cost of hardware to crack a password in 1 year.

From the scrypt paper: estimated cost of hardware to crack a password in 1 year.

假設 bcrypt 加密過的密碼真的也洩漏了,根據上圖可以看得出來原始密碼長度會影響到解密的時間,而為了解決這個問題,可以搭配 HMAC 來解決這問題,具體的演算法如下:

bcrypt(HMAC(password, key), salt) = hash

拿到加密過密碼的人,需要先反解 bcrypt 的值,HMAC(password, key),接著在取得 key,最後在反推 password,透過以上的方式讓密文即使被竊取走了,也不會有立即性的危險。

關於後者 crypto,就以後再說了…

參考文件:

https://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-storage/


Shiny

Experienced JavaScript / Node.js engineer & team lead.
Twitter Facebook Medium LinkedIn GitHub Email