2013年散列認證數據

-1

我面臨着永無止境的問題如何在DB中存儲密碼？。據我最近閱讀的那裏提供了一些以前認爲的安全算法，它們被標記爲不安全。所以我正在努力尋找描述那些不再安全的最新資源。2013年散列認證數據

我在考慮將兩個或三個算法結合起來，但我記得當天它被認爲是不安全的，即將散列暴露給攻擊。我在想的組合是類似的東西：

data_h1 = sha256(sha1(data_salt).sha1([username|email]).sha1(data_peper)) 
data_h2 = sha256(sha1(data_salt).sha1(user_entered_password).sha1(data_pepper)) 

hmac(
sha512, 
data, 
sha512(general_salt.data_h1.data_h2.general_pepper) 
);

凡data_salt和data_pepper是常數，到應用程序中硬編碼，但比general_salt和general_pepper不同它們也硬編碼常量。 [username | email]是用戶在註冊和登錄時提供的值，以及* user_entered_password *（doh！）。

這會以某種方式危及安全嗎？（如果沒有下一步）
由於在發電過程中將會發生的散熱躁狂症會有什麼主要瓶頸嗎？（轉到下一個）
上面顯示的方法的任何建議？

我的問題也適用於PHP，但將是很好的，看看有什麼會你們推薦什麼將您的意見是在一般情況下，b`cuz我認爲這是很常見的任務，許多人仍然使用只有MD5或SHA1（或者更好，以純文本形式存儲）。

來源

2013-10-06 DaGhostman Dimitrov

可能重複的[安全哈希和鹽的PHP密碼]（http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords） – PeeHaa

Pleeeease不使用那些怪異的，完全過時並且在幾秒鐘內可以自行建造「解決方案」。改用新的PHP 5.5密碼散列函數。順便說一句，我刪除了我的正確答案，因爲人們正在降低它（即使它是完全正確的）。 – Sliq

關於5.5的建議是不夠的，因爲它沒有得到廣泛的支持（我幾乎沒有想到提供它的提供商，不包括專用服務器和雲）。可能這就是@Panique DV的原因。由於這種方法非常糟糕（我可以說，但只是試圖說明[很多人不理解的想法]）並引用自己的話：「據我最近看到的，有一些以前考慮過的安全的算法，被標記爲不安全。所以我正在努力尋找描述那些不再安全的資源的最新資源。' –

的主要原因不是單獨使用SHA-1或SHA-256散列爲密碼是他們快速，相對來說。密碼身份驗證容易受到字典攻擊和暴力攻擊的影響，因爲用戶傾向於在其密碼中包含常用單詞，並使用相對較短的密碼，使得它們比加密密鑰更易於猜測。

建議使用像bcrypt和PBKDF2這樣的散列函數，因爲它們是slow。他們可以調整幾乎任何時間;它應該只要即可散列密碼而不會導致不合理的延遲。這將有助於減緩字典攻擊和蠻力攻擊。

但是，這不是密碼存儲唯一的安全考慮因素。

來源

2013-10-06 01:33:19

當「存儲」密碼時，實際上並沒有存儲密碼，因此存儲其單向散列。這是爲了防止即使是有權訪問系統的人學習用戶的密碼。散列的「單向」方面意味着，雖然可以從明文創建散列，但從散列中學習明文是不可能的。

另外，在散列之前，所有密碼都應與salt（隨機數字序列）連接。鹽值應與散列一起存儲在數據庫中。鹽必須是ROW-SPECIFIC，即每個密碼應該有自己的鹽。

爲什麼必須對行進行特定的操作？想象一下黑客以某種方式獲得了數據庫的副本。通常他會面臨一個相當大的蠻力任務。如果只有一個散列，黑客可以檢查所有行並查找出現頻率最高的行，因爲相同的密碼+相同的鹽總是呈現相同的散列。因此，通過這些信息，他可以猜測這些行包含常用密碼。然後他可以使用這些信息來減少他的暴力問題的大小。或者他可以嘗試學習其中一個用戶的密碼，然後就可以在任何具有相同散列的其他用戶帳戶上使用該密碼。鹽的整個目的是防止這種性質的攻擊。

使用體面的單向加密安全哈希與用戶特定的鹽。這是存儲密碼的標準手段。

添加特定於應用程序的「胡椒」（每行都相同，並且必須是密碼隨機的並保存在安全位置）將哈希轉換爲HMAC（基於哈希的消息驗證代碼），它是甚至更好。如果有人知道你的哈希算法和鹽，但不知道胡椒，他將很難猜測密碼。

來源

2013-10-08 02:59:39

2013年散列認證數據

回答

相關問題