Castle ActiveRecord/NHibernate - 密碼加密或散列

Question

使用密碼的正確方法是什麼？您不想以明文形式存儲在數據庫中？ NHibernate/Castle ActiveRecord有哪些選項？

更新： 我對其他人如何用NHibernate/Castle ActiveRecord處理這個問題感興趣。 並且如果有任何內置NHibernate或Castle ActiveRecord的。

Answer 1

您應該加密或散列密碼。散列更安全一些（取決於當然的算法）。因爲它不可逆轉;但是，由於您可以擁有檢索密碼選項，因此加密功能可以更加實用。隨着哈希，你必須生成一個新的密碼..

至於nHibernate /城堡，你應該處理你的業務對象恕我直言，從持久性機制分離算法。

Answer 2

最好的方法是使用UserType。 Here's one實現透明密碼加密。

我會將這樣的常見問題複製到ActiveRecord wiki。

Answer 3

哈希密碼。不要加密 - 它很複雜和/或不安全。在普通的業務線應用程序或網站中，根據其他可驗證標準重置密碼是不可行的。我不知道你是否熟悉哈希密碼的原理，所以我會從基礎知識中解釋...

當用戶最初選擇他們的密碼時，你運行一個文本上的哈希算法。這會產生一個簽名 - 如果將相同的字符串輸入哈希算法，則總是會生成一個輸出。關鍵是你不能從哈希中返回密碼（因此是單向的）。然後您存儲散列，而不是密碼。當用戶返回時，他們必須再次輸入密碼，然後使用相同的算法對其進行哈希處理，並將結果值與數據庫中的值進行比較 - 如果匹配，則知道用戶再次輸入了相同的字符串，但您仍然不會不知道，或者需要知道，它是什麼。這比基於encyrption的解決方案更安全，如果您知道密鑰，您可以隨時恢復明文，而密鑰必須由服務器知道，才能驗證密碼輸入。

在.NET中對字符串進行散列的一個簡單方法是使用System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile()，儘管名稱很長，但它是爲使用ASP.NET Forms身份驗證的用戶提供的簡單函數，但在別處也很有用。您可以指定MD5或SHA1作爲散列算法（或者其他散列算法，如果未來框架版本支持的話）。我推薦SHA1，因爲MD5已知有缺陷，但是隨後SHA1可能也會有。

但是 - 這個方案存在缺陷。如果多個用戶選擇相同的密碼，他們將具有相同的散列。如果黑客訪問您的數據，他們可以運行暴力破解常見字符串並將這些字符與您存儲的數據進行比較。如果他們遇到問題，他們會使用該密碼破解所有帳戶。由於用戶傾向於選擇蹩腳的密碼，並且不願意選擇他們不記得的安全密碼，這使得基於簡單密碼哈希的系統變得脆弱。

你應該做的是鹽散列。這只是意味着將原始數據 - 密碼 - 與一串隨機字符串相加。這種鹽需要儘可能的隨機，並且至少要有幾個字符（我推薦至少5個字符），最好是隨機長度。將salt（未混淆）存儲在數據庫中的哈希鹽+密碼組合旁邊的列中。當用戶返回時，以相同的方式在輸入前綴或後綴鹽，然後像之前一樣進行哈希比較。

這會降低強力攻擊的有效性，因爲即使用戶使用相同的密碼，每個用戶也應該擁有不同的哈希值。您可以安全地將salt存儲在數據庫中，因爲當您知道某些字符串時，如果密碼本身比鹽長且足夠長而且強大到需要很長時間才能通過暴力破解（至少6個字符，至少有一個病例更改，並且有數字或非字母數字，我會說）。

如果有人在無限時間內無限制地訪問您的數據，他們最終會破解哈希密碼。但最終可能會持續數月或數年。如果您知道自己已經被入侵，那麼在出現問題之前，可以讓每個人的密碼更改得當。

Answer 4

我建議不要使用UserType進行單向散列，除非您有一個計劃，以防止在後續調用NullSafeSet（）時不斷重新哈希散列化密碼。

相反，我會建議您在密碼屬性上使用後臺字段，在設置器中應用哈希方法並設置映射以使用字段訪問。

Answer 5

對不起，也許它已不再適合你，但我希望可以幫助別人。

使用uNhAddins是我找到的最簡單的方法，您只需關心HBM即可。

檢查這個hbm example

希望能夠幫助