在代碼或存儲過程中驗證密碼

我目前使用.net/c＃創建登錄和註冊系統。 SQL Server數據庫中保存的用戶名和密碼（散列密碼與鹽等）在代碼或存儲過程中驗證密碼

當我需要驗證密碼，什麼是目前的程序。是否要將用戶輸入的值與salt等值進行哈希值，將它傳遞給存儲過程並在那裏進行比較？或者，與上面相同的步驟，但比較C＃代碼中的密碼？

我想根據最佳實踐和最安全的方法做出決定，以便在此尋找建議以及我應該考慮的項目。

2012-12-11 amateur

我一直給SQL確切的需求。所以我通過鹽之前 - 儲存和加載/比較。 –

無論哪種方式都可以，但我個人會在C＃代碼中進行比較。

我所關注的是，如果有人有對數據庫的訪問，他們可以簡單地更改驗證存儲過程總是返回即使散列不匹配成功。但是，這真正歸結於您更信任的內容 - 您的應用程序代碼安全性或數據庫安全性。

2012-12-11 21:16:17

這是事實，但您也可以從另一個方向來看待這一點。如果您擔心有人可以訪問代碼，然後可能會忽略數據庫響應......這同樣有效。 – PeteH

@PeteH - 確切地說，這就是爲什麼我說它只是歸結爲你更信任的東西 - 你的代碼或數據庫。我可以看到爲什麼人們可能會選擇這種方式。 –

我總是做用戶名/電子郵件的一般驗證，然後從數據庫中使用拉密碼，並比較用戶輸入的值在代碼...我是一個開發商不是DBA這讓我想到的是，數據庫是在支持的代碼（而不是其他方式），所以當局面出現這樣的速度不是影響我推的邏輯代碼..

沒有真正的對錯..只是我會做什麼

編輯：總是加密/哈希你的密碼。

2012-12-11 21:26:25

我不會在數據庫中存儲密碼。你顯然需要存儲一些東西，但我首先通過一個陷門函數來運行它。唯一的問題是活板門在哪裏。 – PeteH

我認爲這顯然不是存儲純文本非哈希密碼。沒想到有必要說。我想我回答了被問到的問題，以便在代碼或數據庫中存放比較邏輯。無論如何，我還是投了你的答案，因爲它比我的完整。 –

我認爲這是一個六和兩個三分之一。對我來說重要的是你沒有存儲密碼，而是一個散列。這是很好的設計。

我唯一要添加的就是保持一致。大概以及處理登錄，當用戶創建帳戶或重置密碼時，您的哈希引擎也將發揮作用。把它全部放在一個黑盒子裏。換句話說，其中一個數據庫或c＃應該很聰明，另一個很笨。

我想你可以從重用來吧....你要重新使用的安全機制，或者與不同的數據庫的任何機會呢？或者上面沒有一層組件？這可能影響你的選擇。

我能想到的唯一的另一件事是你把什麼安全圍繞應用程序（也就是一天的日常業務功能）內變化的數據。這個方面可能影響你的決定嗎？

2012-12-11 21:30:42 PeteH

你應該使用你最瞭解的東西進行比較。除非你確定沒有辦法欺騙存儲過程在密碼錯誤時返回「真」，那麼你最好在代碼中比較它。我勸你對做這樣的事情

我寧願做「從用戶那裏登錄〓[值]選擇*」：

有些莫名其妙都是多餘的，但無論如何，增加安全性。

2012-12-12 16:52:45 marianov

回答