首頁猿問加密/散列數(shù)據(jù)庫(kù)中的純文本密碼

加密/散列數(shù)據(jù)庫(kù)中的純文本密碼

安全

慕運(yùn)維8079593 2019-08-15 16:40:23

加密/散列數(shù)據(jù)庫(kù)中的純文本密碼我繼承了一個(gè)Web應(yīng)用程序，我剛剛在SQL Server數(shù)據(jù)庫(kù)中以純文本形式存儲(chǔ)了超過300,000個(gè)用戶名/密碼。我意識(shí)到這是一件非常糟糕的事情。知道我必須更新登錄和密碼更新過程以加密/解密，并且對(duì)系統(tǒng)其余部分的影響最小，您會(huì)建議從數(shù)據(jù)庫(kù)中刪除純文本密碼的最佳方法是什么？任何幫助表示贊賞。編輯：對(duì)不起，如果我不清楚，我打算問你的加密/哈希密碼的程序，而不是特定的加密/散列方法。我應(yīng)該只是：備份數(shù)據(jù)庫(kù)更新登錄/更新密碼代碼幾小時(shí)后，瀏覽用戶表中記錄密碼的所有記錄并替換每個(gè)記錄測(cè)試以確保用戶仍然可以登錄/更新密碼我想我的關(guān)注更多來自于大量的用戶，所以我想確保我正確地做到這一點(diǎn)。

查看完整描述

3 回答

精慕HU

TA貢獻(xiàn)1845條經(jīng)驗(yàn) 獲得超8個(gè)贊

我想你必須在數(shù)據(jù)庫(kù)中為加密密碼添加一列，然后在獲取當(dāng)前密碼的所有記錄上運(yùn)行批處理作業(yè)，對(duì)其進(jìn)行加密（因?yàn)槠渌颂岬较駇d5這樣的哈希是非常標(biāo)準(zhǔn)的編輯：但不應(yīng)該單獨(dú)使用 - 請(qǐng)參閱其他答案以獲得良好的討論），將其存儲(chǔ)在新列中并檢查所有內(nèi)容是否順利進(jìn)行。

然后，您需要更新前端以在登錄時(shí)散列用戶輸入的密碼，并驗(yàn)證是否與存儲(chǔ)的散列相比，而不是檢查明文與明文。

在最終將明文密碼全部刪除之前，將兩個(gè)列保留一段時(shí)間以確保沒有任何錯(cuò)誤發(fā)生，這似乎是謹(jǐn)慎的做法。

不要忘記，只要密碼被訪問，代碼就必須更改，例如密碼更改/提醒請(qǐng)求。你當(dāng)然會(huì)失去通過電子郵件發(fā)送忘記密碼的能力，但這不是壞事。您將不得不使用密碼重置系統(tǒng)。

編輯：最后一點(diǎn)，您可能要考慮避免我第一次嘗試在測(cè)試床安全登錄網(wǎng)站上犯的錯(cuò)誤：

處理用戶密碼時(shí)，請(qǐng)考慮進(jìn)行散列的位置。在我的例子中，哈希是由在Web服務(wù)器上運(yùn)行的PHP代碼計(jì)算的，但密碼是以明文形式從用戶機(jī)器傳輸?shù)巾撁娴?！這在我工作的環(huán)境中是可以的（ish），因?yàn)樗鼰o論如何都在https系統(tǒng)內(nèi)（uni網(wǎng)絡(luò)）。但是，在現(xiàn)實(shí)世界中，我想你會(huì)想要在離開用戶系統(tǒng)之前對(duì)密碼進(jìn)行哈希處理，使用javascript等，然后將哈希傳輸?shù)侥愕恼军c(diǎn)。

反對(duì) 回復(fù) 2019-08-15

動(dòng)漫人物

TA貢獻(xiàn)1815條經(jīng)驗(yàn) 獲得超10個(gè)贊

基本策略是使用密鑰派生函數(shù)用一些鹽“哈希”密碼。salt和哈希結(jié)果存儲(chǔ)在數(shù)據(jù)庫(kù)中。當(dāng)用戶輸入密碼時(shí)，鹽和它們的輸入以相同的方式進(jìn)行散列并與存儲(chǔ)的值進(jìn)行比較。如果匹配，則對(duì)用戶進(jìn)行身份驗(yàn)證。

細(xì)節(jié)決定成敗。首先，很大程度上取決于所選擇的哈希算法。像PBKDF2這樣的密鑰派生算法，基于基于散列的消息認(rèn)證代碼，使得在計(jì)算上不可行地找到將產(chǎn)生給定輸出的輸入（在這種情況下，密碼）（攻擊者在數(shù)據(jù)庫(kù)中找到了什么））。

預(yù)先計(jì)算的字典攻擊使用預(yù)先計(jì)算的索引或字典，從散列輸出到密碼。散列很慢（或者它應(yīng)該是，無論如何），因此攻擊者一次性散列所有可能的密碼，并以這樣的方式存儲(chǔ)索引結(jié)果，即給定散列，他可以查找相應(yīng)的密碼。這是時(shí)間空間的經(jīng)典權(quán)衡。由于密碼列表可能很大，因此有一些方法可以調(diào)整權(quán)衡（如彩虹表），這樣攻擊者就可以放棄一點(diǎn)速度來節(jié)省大量空間。

使用“加密鹽”阻礙了預(yù)計(jì)算攻擊。這是一些使用密碼進(jìn)行哈希處理的數(shù)據(jù)。它不需要是秘密，它只需要對(duì)給定的密碼不可預(yù)測(cè)。對(duì)于鹽的每個(gè)值，攻擊者需要一個(gè)新的字典。如果使用一個(gè)字節(jié)的salt，攻擊者需要256個(gè)字典副本，每個(gè)副本使用不同的鹽生成。首先，他使用salt查找正確的字典，然后他使用hash輸出來查找可用的密碼。但是如果添加4個(gè)字節(jié)怎么辦？現(xiàn)在他需要40億份字典。通過使用足夠大的鹽，排除了字典攻擊。實(shí)際上，來自加密質(zhì)量隨機(jī)數(shù)發(fā)生器的8到16個(gè)字節(jié)的數(shù)據(jù)是很好的。

通過預(yù)先計(jì)算表，攻擊者可以在每次嘗試時(shí)計(jì)算哈希值。現(xiàn)在找到密碼需要多長(zhǎng)時(shí)間完全取決于散列候選人所需的時(shí)間。通過散列函數(shù)的迭代來增加該時(shí)間。數(shù)字迭代通常是密鑰導(dǎo)出函數(shù)的參數(shù); 今天，許多移動(dòng)設(shè)備使用10,000到20,000次迭代，而服務(wù)器可能使用100,000或更多。（bcrypt算法使用術(shù)語“成本因子”，它是所需時(shí)間的對(duì)數(shù)度量。）

反對(duì) 回復(fù) 2019-08-15