数据库里账号的密码,这样存放最安全!
作者:小蔣不素小蔣
來源:cnblogs.com/xjnotxj/p/12716981.html
最早在大學的時候,只知道用 MD5 來存用戶的賬號的密碼,但其實這非常不安全,而所用到的哈希函數,深入挖掘,也發(fā)現并不簡單……
一、普通的 Hash 函數
哈希(散列)函數是什么就不贅述了。
1、不推薦
RC4, MD4, MD5, SHA-0, SHA-1, DES, 2DES 等
2、推薦
SHA-2(SHA-256, SHA-384, SHA-512)、SHA-3、Blake2 等
美國國家標準和技術協會(NIST)宣布,2010 年后開始逐步取消 SHA-1 作為安全哈希算法的資格,取而代之的是其更強大的變異算法:SHA-224、SHA-256、SHA-384 和 SHA-512。無論是否遵循 NIST 的標準,至少使用 SHA-256 算法加密密碼總是好的。
二、應對普通哈希容易被破解的策略
就像攻與矛的互相增強,哈希函數哪怕用到 SHA-3 以上,都還是有被輕易破解的風險。于是我們有其他額外的辦法來解決這個問題。
1、加鹽(salt)
加鹽就是對目標字段哈希前,拼接上另一個字段(salt)。
注:鹽值加到字段之前較為普遍。
加鹽對防彩虹表很有效。
注意點:
-
鹽不能太短
-
鹽不能重復使用(否則一破解,所有的都遭殃)
-
鹽隨機變化(例如,雖用戶名不重復,但用戶名不能拿來當鹽)
-
鹽的本質是將無差別攻擊轉化為針對性攻擊。
1.1、【拓展】針對 salt 的另一種做法 —— HMAC
HMAC(Keyed-Hashing for Message Authentication)其實也是一種特殊的加鹽,只是這個 salt 用更安全的密鑰代替了。
具體介紹:
https://www.cnblogs.com/xjnotxj/p/11934756.html
2、慢哈希
高端的顯卡(GPU)和定制的硬件可以每秒進行數十億次哈希計算,因此這類攻擊依然可以很高效。為了降低攻擊者的效率,我們可以使用慢哈希,即迭代進行很多次哈希運算。
那么迭代多少次比較安全呢?來自 NIST 官方的建議:
-
2000 年 9 月,建議迭代一千次
-
2015 年 - 2018年,建議迭代一萬次
-
2017 年 6 月,建議迭代十萬次
三、密碼哈希函數(Password Hash)
密碼哈希函數(Password Hash)可以用來應對普通哈希容易被破解的問題(也用到了上面所提到的兩個策略)。
下面列舉的順序是按照時間順序,安全程度和推薦指數也逐級遞增。
1、PBKDF2
比較老,很少有人用了,略。
2、Bcrypt
這是我司目前用的。(不過有過時的隱患,建議換掉)
(1)介紹
bcrypt 是由 Niels Provos 和 DavidMazières 基于 Blowfish 密碼設計的密碼哈希函數,于 1999 年在 USENIX 上提出。
bcrypt 函數是 OpenBSD 和其他系統(包括某些 Linux 發(fā)行版,例如 SUSE Linux)的默認密碼哈希算法。
(2)使用(Node.js)
安裝:
npm?i?bcryptjsbcryptjs 跟 C++ 的 bcrypt 兼容,但因為是純 JavaScript 編寫的,因此速度較慢(約 30%)。
用法:
//Sync 方法(Async 方法略):??const?bcryptjs?=?require('bcryptjs');??//?1、生成?安全因子?? const?salt?=?bcrypt.genSaltSync(10);?? //?2、執(zhí)行?哈希函數?? const?password?=?bcryptjs.hashSync(plainPassword,?bcryptjs.genSaltSync(salt));??//?另一種方法:快速執(zhí)行?? const?SALT_FACTOR?=?10;?? const?password?=?bcryptjs.hashSync(plainPassword,?bcryptjs.genSaltSync(SALT_FACTOR));??//?3、比較是否相等?? bcryptjs.compareSync(plainPassword,?password);注:代碼里出現的安全因子,值的大小決定了哈希函數會有多慢。(即慢哈希)
3、Scrypt
沒用過,略。
4、Argon2
(1)介紹
2013 年 NIST(美國國家標準與技術研究院)邀請了一些密碼學家一起,舉辦了密碼哈希競賽 PHC(Password Hashing Competition)。Argon2 在 2015 年 7 月贏得了冠軍。
大賽列出了參賽算法可能面臨的攻擊手段:
-
哈希算法破解(原值還原、哈希碰撞等);
-
查詢表/彩虹表攻擊;
-
CPU 優(yōu)化攻擊;
-
GPU、FPGA、ASIC 等專用硬件攻擊;
-
旁路攻擊;
(2)使用(Node.js)
1、準備
You?can?skip?this?section?if?the?prebuilt?binaries?work?for?you.??You?MUST?have?a?node-gyp?global?install?before?proceeding?with?install,?along?with?GCC?>=?5?/?Clang?>=?3.3.?On?Windows,?you?must?compile?under?Visual?Studio?2015?or?newer.??node-argon2?works?only?and?is?tested?against?Node?>=10.0.0.??---??OSX?? To?install?GCC?>=?5?on?OSX,?use?homebrew:??$?brew?install?gcc?? Once?you've?got?GCC?installed?and?ready?to?run,?you?then?need?to?install?node-gyp,?you?must?do?this?globally:??$?npm?install?-g?node-gyp?? Finally,?once?node-gyp?is?installed?and?ready?to?go,?you?can?install?this?library,?specifying?the?GCC?or?Clang?binary?to?use:??$?CXX=g++-6?npm?install?argon2?? NOTE:?If?your?GCC?or?Clang?binary?is?named?something?different?than?g++-6,?you'll?need?to?specify?that?in?the?command.2、安裝
npm?i?argon23、使用
const?argon2?=?require('argon2');??(async?()?=>?{??try?{??//?const?hash?=?await?argon2.hash("password");??//?更多選項(以下都是默認值)??const?hash?=?await?argon2.hash("password",?{??type:?argon2.argon2i,??hashLength:?32,?//?哈希函數輸出的字節(jié)長度(請注意,生成的哈希是使用Base64編碼的,因此長度將增加約1/3)??timeCost?:?3,?//?時間成本是哈希函數使用的通過次數(迭代次數)??memoryCost:?2?**?16,?//?默認?4096(單位?KB,即?4MB)??parallelism?:1,?//用于計算哈希值的線程數量。每個線程都有一個具有memoryCost大小的內存池??})??console.log("hash",?hash)??const?is?=?await?argon2.verify(hash,?"password")??console.log("is",?is)?//?true??}?catch?(err)?{??console.error("err",?err)??}?? })()(3)參數
1、type:
-
argon2d 更快且對GPU攻擊具有高度抵抗力,這對于加密貨幣很有用
-
argon2i 速度較慢且可以抵御權衡攻擊,因此首選用于密碼哈希和密鑰派生
-
argon2id 是上述內容的混合組合,可以抵抗GPU和權衡攻擊
因為我們是用于密碼的 hash,用默認的 argon2i 即可。Java知音公眾號內回復“面試題聚合”,送你一份面試題寶典!
2、(慢)哈希相關參數
①?memoryCost?內存開銷,它定義了內存的使用情況
好的起點是 0.75 *(RAM / number_of_users) 起步。
②?parallelism?并行程度,它定義了線程的數量
最佳起點是內核數。
③?timeCost?時間開銷,它定義了執(zhí)行的時間
建議在系統上運行它,并確定與內存和處理器使用時間限制相匹配的最大參數。
如前所述,本質是在安全性和可用性之間取得平衡。
3、其他參數
-
salt:默認值是未設置,將生成加密安全的隨機鹽。
-
saltLength:默認16。
-
version:您不應更改此設置,因為最新版本更強大。
5、密碼哈希是如何解決普通哈希容易被破解的問題
上面介紹了 二、應對普通哈希容易被破解的策略 ,我們可以看看密碼哈希是如何運用并符合這些策略的。
(1)針對 salt
密碼哈希使用 CSPRNG(Cryptographically Secure Pseudo-Random Number Generator)密碼學安全偽隨機數生成器生成鹽。
CSPRNG 是加密安全(Cryptographically Secure)的,(加密安全的意思即)意味著用它產生的隨機數更加隨機,且不可預測。
普通的計算機隨機數算法并不是很隨機。
注:鹽值本身就在存在于哈希后的字符串中(其實還可能包括版本、慢哈希迭代次數等),當調用跟明文比對的方法時,模塊內部會提取出鹽值進行驗證。
(2)針對 慢哈希
Bcryoy 的安全因子和 Argon2的 timeCost 參數,都是針對慢哈希的配置。
6、結論
我司使用的 Bcrypt 其實在今年(2020年),已經不安全了,推薦至少使用 Scrypt,有條件上 Argon2。
四、常見問題
問1:我用我自己實現哈希算法,不用公開現成的,越古怪越好,壞人不就猜不到了嗎?
答:不建議。
首先介紹下密碼學上的柯克霍夫原則(Kerckhoffs's principle,也稱為柯克霍夫假說、公理、或定律),由奧古斯特·柯克霍夫在 19 世紀提出:即使密碼系統的任何細節(jié)已為人悉知,只要密匙(key,又稱密鑰或秘鑰)未泄漏,它也應是安全的。信息論的發(fā)明者克勞德·香農則改成說:“敵人了解系統”,這樣的說法則稱為香農箴言。
基于這個原則:
-
你自己實現的再古怪,畢竟你不是密碼專家,很難確保不被壞人破解(可能自己實現后看似復雜,實際更容易破解了)。
-
如果自己包含哈希算法的代碼泄露,它很脆弱,難保不會被壞人破解。
問2:既然現在都是 https,前端傳給后端的明文密碼,就懶得加哈希了,可以嗎?
還是建議前端也進行哈希(雖然前端的哈希算法容易暴露)。不要漏掉任何一個環(huán)節(jié)。
五、實操
Dropbox 公司曾公開分享過自己對用戶賬號的密碼加密的策略,使用了三層加密:
1、password
即明文密碼。
2、SHA512
在 bcrypt 前做 SHA512,是因為有些 bcrypt 實現會把散列值長度截至 72 字節(jié),從而降低了密碼的熵值,而有的則允許變長密碼,這樣容易受到 DoS 攻擊。使用 SHA512 散列可以得到固定長度的 512 字節(jié)散列值,避免了上述的兩個問題。
”而有的則允許變長密碼,這樣容易受到 DoS 攻擊“,這句話我不是很理解,待寫。
3、bcrypt
上面說過,不贅述了。
4、AES256
AES256 會用到密鑰,俗稱胡椒粉(pepper)。密鑰需要被單獨存儲,最好存儲在外部系統:如物理上隔離的服務端、甚至特殊的硬件設備(如 YubiHSM) 。
這里的 AES256 也可以用 HMAC 代替。不過前者安全性更好些。
總結
以上是生活随笔為你收集整理的数据库里账号的密码,这样存放最安全!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Java 类中可以覆盖静态方法吗?
- 下一篇: Netty实现自定义协议