我想就我需要發送用戶和密碼組合的任何移動應用程序構建的流程發表一些意見。 我的想法是使用AES-256加密密碼，生成一個隨機密碼和IV來生成密鑰。這個想法是，當第一次生成密碼時，它會向服務器發送加密密碼和IV。 IV和加密的密碼將被存儲在服務器上，在redis DB中，並且密鑰和加密的密碼將僅在移動設備上（IV不會被存儲在設備上）。因此，每次用戶需要登錄時，發送給服務器，加密的密碼和密鑰，在存儲了IV的情況下，服務器使用剛剛發送的密鑰和IV發送的密鑰解密發送的加密密碼和保存在數據庫中的密碼已經在服務器上。流從移動設備發送加密密碼到服務器
如果用戶想要更改密碼，則會再次生成加密的密碼，密鑰和IV，並且如果它們匹配，也會發送舊密碼（密鑰和加密密碼），值將在服務器中更新併發送通知給客戶也更新它們。
所有這些交易都將發生在SSL隧道內部。
你覺得這樣很安全嗎？如果不是爲什麼？任何其他選項來從移動設備到服務器以安全的方式加密/解密密碼？
問候。
做到這一點的最好方法是在發送數據併發送散列之前，在客戶端執行密碼散列。然後讓服務器對該散列執行自己的哈希操作，以便密碼永遠不必離開客戶端，並且純文本密碼不能從強制存儲的散列派生。
我列出的KDFs（pbkdf2，scrypt，bcrypt）很耗費時間，所以你可能不想在客戶端和服務器上執行它，除非安全性比平常更重要。 KDF用於防止某人從散列中強制密碼。這意味着，如果存儲用戶哈希的表損壞，則用戶密碼的純文本仍然安全。例如，如果您在客戶端上執行KDF並且說服務器上的KDF的簡單醃製MD5產生了散列，那麼用戶明文密碼將是安全的，但對於能夠訪問存儲的散列（意味着服務器已被盜用）以該用戶身份登錄。如果您的網站/應用程序是stackoverflow，則可能無關緊要，如果服務器本身已被入侵，用戶帳戶可能會受到影響。另一方面，如果您是PayPal，那麼可以訪問帳戶的人可以訪問用戶銀行帳戶，而這些用戶銀行帳戶只需訪問哈希表就無法完成。在這種情況下，在客戶端和服務器上執行KDF將是最佳選擇。
至於使用SSL，如果您有一種驗證服務器實際上是您的服務器並且沒有MITM正在進行的方法，那很好。如果其中任何一個被泄露，那麼以純文本格式發送密碼將允許攻擊者訪問明文密碼
感謝您的詳細回答，哈希處理2次將是最好的（即使是消費，我會保存散列，所以我只是做一次）。我的應用程序不是寶，而是我拿用戶證書的安全性很嚴重，我想避免，如果這曾經得到在某種程度上受到影響（試圖採取一切預防措施，我可以，但就像每個人都知道，沒有系統是100 ％安全），攻擊者能夠獲取密碼在我的網站不使用，但在其他地方的用戶（的東西，通常發生） – 2013-02-14 20:50:43
啊，這與大多數網站主要關注使用的是你不想要讓攻擊者獲得密碼的純文本版本，這是密鑰派生函數（KDF）所防止的。不知道你是否遵循了所有的安全漏洞，去年網站的，但他們是在純文本，或者可以很容易地bruteforced一個簡單的散列算法的所有存儲密碼。只要你在某個地方使用KDF，即使你的密碼哈希表被盜，你的用戶仍然是安全的。 – Eric 2013-02-14 20:56:57
爲什麼您需要存儲加密的密碼？存儲散列有什麼問題？ – Eric 2013-02-14 19:42:16
你的意思是使用河豚？爲什麼sha1不安全，據我所知 – 2013-02-14 19:53:45
是什麼？ blowfish和sha1都是哈希算法，而不是加密密碼。我建議使用pbkdf-2，bcrypt或scrypt來存儲密碼散列，而不是存儲加密的密碼。 – Eric 2013-02-14 20:07:34