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