我們目前正在開發一個.Net的網絡應用程序，它也會有Android，iPhone和Windows Mobile 8應用程序佔用它。所有這些應用程序都需要有統一的登錄系統。我們的網站和網絡服務將使用SSL，但顯然我們希望盡一切努力確保用戶密碼的安全。因此，我們正在尋找一種通用密碼散列函數，可以在上述平臺中使用。通過多種平臺（Andorid，iPhone，W8M）進行密碼散列
目前我們發現的唯一常見的是SAH256，但是我想用一些更強的東西。 C＃有我想使用的Rfc2898DeriveBytes類（可以在網站和Win8 Mobile中使用），但是有沒有針對Android/Java和iOS/Objective C的這種實現？如果不能使用這將是我們的下一個最佳選擇？
PBKDF2不適合您的情況。它主要用於在攻擊者已經擁有數據（即加密文件）時防止攻擊。它通過吃掉CPU來迫使暴力強制延遲。因爲您正在執行auth服務器端，所以您可以輕鬆地保存一些CPU，並且只需等待一兩秒就可以向客戶端發送響應，如果他們的密碼錯誤。只需使用鹽漬散列（如HMAC），你就會好起來的。
如果您使用的是SSL，那麼您的密碼是安全的。你可以做得更好的唯一方法是實現完整的公鑰密碼，這可以防止MITM攻擊。 SSL甚至有這個內置。
通過網絡發送密碼散列並不比發送密碼更安全。是的，密碼文本對攻擊者是隱藏的，但他們仍然有散列，如果他們有這些，他們不需要密碼。在SSL的情況下，您的純文本也受到保護。
很好的一點。這對我們的移動開發者來說也更好。謝謝:) – Wizardskills
除非你是真正的密碼專家，否則很難做得比SSL更好。無論如何，「完整的公鑰密碼」意味着什麼？ PBKDF2是一個完全有效的標準算法，可用於哈希密碼。 HMAC與鹽漬散列不完全相同。主要觀點仍然是：通過SSL發送任何潛在的敏感信息，並且最重要的是*確保您正確驗證服務器證書*。否則，您會安全地將東西發送給您不認識的人（潛在的攻擊者）。 –
我並不是故意說PBKDF2是一種無效或非標準算法，只是它不適合他正在嘗試做的事情。 –
存儲用戶密碼並在登錄嘗試期間進行比較時，應在後端使用密碼散列函數。
登錄之情況：
用戶通過應用程序的版本之一在SSL上發送密碼。
後端服務器散列從用戶發送的密碼，從數據存儲中檢索存儲的散列，比較使用存儲的散列發送的密碼的散列。
哈希匹配，允許用戶訪問，否則訪問被拒絕。
SSL加密可防止在客戶端傳輸過程中暴露密碼，將密碼存儲爲散列，防止數據庫被破壞時泄露用戶密碼。
使用這個scenerio，由於哈希全部在後端服務器完成，所以只需要哈希算法的一個實現。
從UI獲取密碼後應該立即對密碼進行散列處理，並且明文應該清除或至少爲GC釋放。依靠一種特定的技術，即使它是目前的行業標準，也不是一個很好的做法。 http://www.informationweek.com/security/vulnerabilities/black-hat-security-pro-shows-how-to-bypa/214501930 –
@StenPetrov在收集密碼後對密碼進行散列並不會增加任何安全性。如果攻擊者可以訪問密碼並將其發送給服務器，則他們可以訪問該密碼並將其發送到服務器。 – Rawling
@拉鋸你是對的。唯一需要考慮的是用戶在多個服務中使用相同的密碼。因此，獲得的散列不能用於嘗試和訪問不同的服務（除非它們全部使用相同的散列算法），而明文密碼可以用於此。 – Mario
相關：http://stackoverflow.com/q/9375004/716216 –
爲什麼他們都需要相同的技術（哈希算法）？那是因爲客戶應該散列輸入密碼然後集中檢查？爲什麼不只是使用SSL，並有中央系統散列和比較。你能否解釋爲什麼在任何地方都需要使用相同的哈希算法。 –