我想对我为需要发送用户和密码组合的任何移动应用程序构建的流程提出一些意见。我的想法是使用 AES-256 加密密码，生成随机密码和 IV 来生成密钥。这个想法是，当密码第一次生成时，它会将加密的密码和 IV 发送到服务器。IV 和加密密码将存储在服务器上，在 redis 数据库中，密钥和加密密码将仅在移动设备上（IV 不会存储在设备上）。因此，每次用户需要登录时，将加密密码和密钥发送到服务器，并存储 IV，服务器使用刚刚发送的密钥和 IV 解密发送的加密密码和保存在数据库中的密码已经在服务器上。
如果用户想要更改他们的密码，加密密码、密钥和 IV 会再次生成，如果它们匹配，也会发送旧密码（密钥和加密密码），值会在服务器中更新并向客户端发送通知也更新它们。
所有这些事务也将在 SSL 隧道内进行。
你认为这安全吗？如果不是为什么？以安全方式从移动设备到服务器加密/解密密码的任何其他选项？
问候。
最好的方法是在发送数据并发送哈希之前在客户端对密码进行哈希处理。然后让服务器对该散列进行自己的散列，以便密码永远不必离开客户端，并且不能通过暴力破解存储的散列来获得纯文本密码。
我之前列出的 KDF（pbkdf2、scrypt、bcrypt）非常耗时，因此您可能不想在客户端然后在服务器上执行此操作，除非安全性比正常情况更重要。KDF 用于防止有人从哈希中暴力破解密码。这意味着，如果存储用户哈希的表被泄露，用户密码的纯文本仍然是安全的。例如，如果您在客户端执行 KDF，并在服务器上说 KDF 生成的哈希的简单加盐 MD5，那么用户的纯文本密码将是安全的，但对于能够访问存储的哈希（意味着服务器已被入侵）以该用户身份登录。如果您的站点/应用程序是 stackoverflow，那么如果服务器本身已经受到威胁，那么用户帐户是否受到威胁可能并不重要。另一方面，如果您是贝宝，则可以访问帐户的人可以访问用户的银行帐户，而他们仅通过访问哈希表就无法做到这一点。在这种情况下，在客户端和服务器上都执行 KDF 将是最佳选择。
至于使用 SSL，如果您有一种方法可以验证服务器实际上是您的服务器并且没有 MITM 发生，那就太好了。如果其中任何一个被泄露，那么以纯文本形式发送密码将允许攻击者获得对纯文本密码的访问权限