Web服務，Android客戶端，SSL

Question

我正在使用該服務編寫Web服務（Rest）和Android應用程序。 沒有登錄，沒有會話 - 而是登錄數據（用戶名，密碼）發送到該服務的每次調用（通過org.apache.http.client.methods.HttpPost在org.apache.http。 impl.client.DefaultHttpClient）。 爲了確保通信安全，我將在我的網絡服務器上「安裝」一個簡單的SSL證書（128位），並通過「https」撥打電話。 這是正確的方法嗎？ 以這種方式保護通信（通過POST發送密碼）？

服務器將爲密碼存儲一些有點散列（md5，sha1）...應該Android發送密碼並讓webservice生成散列或者是否應該發送散列？

在Android上，我是否存儲密碼或散列（私人偏好）？

Answer 1

這是一個很大的問題。在簡短答案的範圍內比可以輕鬆解決的問題要大。儘管您提出這些問題，但我認爲這是一件好事，因爲這表明您意識到所涉及的風險。

我可以嘗試給你一些指示，至少。首先，md5和sha1不足以保證用戶證書的安全，散列和散列哈希的過程本身就是一個章節。檢查出Secure Salted Password Hashing - Doing it Right，也許Our password hashing has no clothes爲一些背景。並檢查出bcrypt或PBKDF2作爲更適合的哈希算法。

當談到體系結構時，我建議考慮在一次調用中對用戶進行身份驗證以獲得某種身份驗證令牌，然後將此令牌用於後續通信，而不是發送憑據我每一個電話。這不僅會提高安全性，還會提高性能，尤其是在使用故意耗時的加密哈希算法（如bcrypt或PBKDF2）時。另外，請記住，令牌應與用戶身份相關聯，而不僅僅是一些「已驗證的會話」。這是你可能不應該實現的東西，而是依賴於你正在使用的框架中的一些機制。會話管理很棘手，例如Ramping up ASP.NET Session Security（< - 不是ASP.NET特定的）。

在任何情況下，都應該在存儲散列的地方執行散列。也就是說，認證，散列和存儲都應該是服務的責任，而不是客戶端。謹防任何類型的實現容易受到replay attacks的影響。

SSL是一切都很好，並且（絕對必須，甚至），但如果是我，我會考慮保護不僅傳輸層，而且調用者被授權使用該服務，即使用證書。我不熟悉Android平臺的內部工作原理，所以我不能就如何在這種情況下安全地完成這項工作提出建議。

最後（我有一個會議要參加;），如果你認爲這一切都可能是「矯枉過正」，請記住60 percent of users use the same password，作爲開發者，我們有責任照顧他們投資的信任我們的技能。

祝你好運，並保持您的安全解決方案的追求！