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