您應該將其存儲在單個字段中。

我知道這對於來自數據庫背景的人們來說似乎有點不直觀，在這種情況下，操作方法是規範化數據並且使用序列化字符串被認為是醜陋的。但是從安全實踐來看，這是很合理的。

為什麼？因為單個開發人員需要使用的最小單元就是該完整字符串。這就是應用程序需要傳遞給哈希庫的功能，以檢查所提供的密碼是否正確。從開發人員的角度來看，哈希庫可以是一個黑匣子，並且她不必擔心那些討厭的部分的實際含義。

這是一件好事，因為大多數開發人員都是不完善的人（我知道，因為我是我自己）。如果您讓他們將字符串分開，然後再嘗試將它們重新組合在一起，它們可能會搞砸，例如給所有用戶相同的鹽或完全不加鹽。

僅將參數存儲在代碼中也是一個壞主意。隨著處理器變得越來越快，您將來可能希望增加成本因素​​。在遷移階段，不同的密碼將具有不同的成本因素。因此，您將需要有關密碼級別的信息，以了解用於加密它的成本因素。

您所缺少的是哈希處理原始數據，減去原始字符串。當您要針對哈希驗證字符串時，請使用提供的字符串以及原始哈希數據（成本，鹽等），然後生成一個新的哈希。如果新哈希與舊哈希匹配，則對該字符串進行驗證（換句話說，該字符串永遠不會解密，它會重新哈希）。

含鹽無助於您蠻力。鹽是哈希表的重要組成部分，就像不倒翁是鎖的一部分一樣。如果您取出其中任何一個，則沒人可以使用它。

分隔存儲毫無意義。在大多數情況下，您必須重新組裝完成的哈希以對其進行驗證。這就是為什麼默認情況下所有組件都存儲在一個方便的字符串中的原因。

是的，您可以將其存儲在單個字段中，並且許多數據庫/應用程序將salt + hash存儲在單個字段/文件中。

最著名的是Linux（不是Linux DB），使用以下格式將哈希存儲在/ etc / shadow文件中：

“ $ id $ salt $ hashed”，這是由crypt（C）產生的密碼哈希的可打印形式，其中“ $ id”是使用的算法。 （在GNU / Linux上，“ $ 1 $”代表MD5，“ $ 2a $”代表Blowfish，“ $ 2y $”代表Blowfish（8位字符的正確處理），“ $ 5 $”代表SHA-256，“ $ 6 $ “是SHA-512，[4]其他Unix可能具有不同的值，例如NetBSD。

（來源： https://en.wikipedia.org/wiki/Passwd）

鹽並不意味著是秘密的（或至少不比散列更秘密），其主要目的是使暴力破解更加困難，因為攻擊者必須使用

但是您的問題更加細微-因為您不僅在詢問鹽，而且還詢問參數，例如哈希算法，迭代計數和鹽。

假設您有很多用戶，並且您使用SHA1作為哈希算法，那麼您的數據庫字段將是類似 SHA1：SALT：HASH 的東西。

如果您想將數據庫升級到BCRYPT，您將如何做？

Typi毫無疑問，您將部署一些代碼，以便在用戶登錄時驗證密碼，如果有效，則可以使用較新的算法重新哈希密碼。現在，該用戶的字段如下所示： BCRYPT：SALT：HASH 。

但是隨後某些用戶將位於SHA1上，而其他用戶將位於BCRYPT上，因為該用戶位於用戶級別，您需要使用參數來告訴您的代碼哪些用戶將屬於數據庫中的用戶。

簡而言之，將參數和哈希存儲在單個字段中是可以的，但是出於任何原因將它們拆分出來（效率，更簡單的代碼等）也可以。不能的是將其存儲在您的代碼中：）

TL：DR

特洛伊·亨特（Troy Hunt）最近發布了一個播客，建議與採用上述方式遷移到BCRYPT相比，簡單地獲取當前正在使用的所有SHA1哈希更為有效。

有效地 BCRYPT（SHA1（clear_password））

當用戶登錄時，

  BCRYPT（SHA1（clear_password））== <db_field>  

通過這種方式，平台上的每個人都可以一次升級，而您的數據庫沒有多個哈希密碼格式。非常乾淨而且非常好。

我認為這個想法很合理，但是即使每個人都一次遷移，它也不是瞬時的。除非您願意接受應用程序的某些停機時間（在重新哈希所有密碼的同時），否則仍有一些時間間隔，有些用戶使用BCRYPT，有些用戶使用SHA1，因此您的數據庫仍應存儲哈希算法的參數，您的代碼將基於該算法執行。

從安全的角度來看，salt和哈希密碼存儲在單個字段還是單獨的字段中都沒有關係，儘管為簡單起見，我傾向於使用單個字段。分開它們的唯一原因是，如果您的應用程序代碼需要將鹽和密碼分別傳遞給驗證功能。如果您的應用程序代碼只需要一個組合的字符串，那麼您也可以用這種方式存儲它。

例如，較早的ASP.NET Membership將密碼哈希和salt分為兩個DB字段，並且較新的ASP.NET Identity在單個DB字段中具有哈希和鹽，因此又對較新的功能進行了修改，以將單個字符串作為輸入和輸出來處理。

可以將其存儲在SQL數據庫的一個字段中（在這種情況下為varchar（99））

否。數據的大小可能會在某些時候改變。除非規範指出大小始終為99，並且該 ever 不得有任何變化，否則應使用varchar（MAX）字段。讓數據庫滿足存儲需求。

要知道它的安全性，我們必須了解鹽的用途。

鹽有一些用途（我能想到）

1. 防止字典攻擊
ol>

字典攻擊是將邏輯詞用作密碼的一部分。原型是單詞 password 甚至是 P @ ssW0rd 。人是不完美的，與單詞和數字的隨機字符串相比，他們更容易記住單詞。字典攻擊依靠此來縮短暴力攻擊的路徑。顯然，如果我們向其中添加隨機的內容，那麼這將使這種類型的攻擊變得不可能或毫無意義，並將它們重新強加於人。

如果攻擊者知道使用的鹽，他們將必須編輯每個密碼的所有字典文件，並且假定他們知道如何將鹽添加到原始密碼中。詞典列表的一大好處是說您需要1000個密碼和100萬個詞典單詞。然後，您循環瀏覽它們，以嘗試使用較弱的密碼進行一些匹配。因此，必須將一百萬個單詞編輯1000次實際上是不實際的。

1. 防止哈希或Rainbow表攻擊。
ol>

A Rainbow表是預先計算哈希並將其存儲在某種數據庫中的地方。例如，您可以使用MD5，然後開始對隨機內容進行哈希處理並保存。然後，當您想破解密碼時，只需在Rainbow表中查找即可。

如果攻擊者吃了鹽，他們必須為使用的每種鹽重新編譯彩虹表。這種攻擊的好處是可以提前編譯數據並一再重複使用。這使他們重新使用蠻橫的密碼。通過對所有密碼加鹽和加鹽，這基本上意味著您必須重新計算每種鹽的彩虹表。這就是為什麼在每個密碼前使用不同的鹽很重要。

摘要

這些原因中沒有一個真正依賴於鹽的秘密。顯然，如果攻擊者知道了鹽分，它們的強度都會降低。但是他們獲得的其他信息將始終為他們提供幫助。因此，我不會說要去做廣告，但是有一種說法是基於模糊性的……。

免責聲明我絕對不是密碼專家，但是這些是我想到鹽時想到的幾個最重要的原因。

希望有幫助。

鹽僅用於阻止彩虹表攻擊，因此鹽可能會使用哈希密碼存儲，就像在最新的GNU / Linux系統上將鹽存儲在/ etc / shadow中一樣。