ASP.Net身份2.0和Android的其餘API

我有一個MVC網站使用身份驗證的asp.net身份2.0。我也在爲Android手機應用程序開發相同數據庫的REST API。我想使用身份2.0哈希密碼在REST API中進行身份驗證，但不能從Android應用發送明文密碼。 Android應用程序必須以與身份2.0用戶管理器相同的方式對密碼進行哈希處理，然後我可以比較從Android應用程序發送的密碼和存在於AspNetUsers表中的密碼。問題是，我找不到任何實現或準則來實現Java/Android中Identity 2.0的PasswordHasher。ASP.Net身份2.0和Android的其餘API

這裏是身份2.0 PasswordHasher的C＃代碼https://raw.githubusercontent.com/aspnet/Identity/5480aa182bad3fb3b729a0169d0462873331e306/src/Microsoft.AspNetCore.Identity/PasswordHasher.cs

請幫助，因爲過去兩天我堅持..在客戶端上

來源

2017-03-28 Zeeshan

哈希密碼是一個壞主意。它如何使它變得更好，然後以純文本形式發送密碼？如果MiTM攻擊者獲取散列密碼 - 他將獲得登錄到系統的所有內容。是的，您並未傳輸原始密碼，但是您傳輸的散列實際上已成爲密碼，並且無論如何您都將密碼的純文本散列存儲在數據庫中。

另外鹽呢？在標識框架中，鹽與散列存儲在相同的字段中 - 它們被相互附加到一起。如果您在同一個字符串上運行PasswordHasher.HashPassword() 10次，則會得到10個不同的結果，因爲此結果已包含salt。如果您嘗試在客戶端上運行此操作，則每次都會得到不同的字符串，您將無法與已存儲在數據庫中的哈希/鹽進行比較。所以你必須從服務器以某種方式傳遞salt以便能夠使用相同的salt進行散列。這使得它過於複雜並且容易被錯誤地完成。

不要試圖自己創造安全系統。通過加密連接以純文本形式傳遞用戶名/密碼，並讓框架爲您做散列/持久化。

來源

2017-03-28 13:58:21 trailmax

將密碼散列在客戶端上的好處在於，您不一定要讓系統更安全，但是您爲客戶端提供了額外的安全層。在發生MiTM攻擊時，攻擊者將不會在用戶使用相同密碼的其他應用程序中使用明文密碼。 – keelerjr12

ASP.Net身份2.0和Android的其餘API

回答

相關問題