我想要一些关于我正在为需要发送用户名和密码组合的移动应用程序构建的流程的一些意见。我的想法是使用AES-256加密密码,生成一个随机的密码短语和IV来生成密钥。其思想是,当第一次生成密码时,它将加密的密码发送到服务器,而IV和加密的密码将存储在服务器的redis DB中,并且密钥和加密的密码将仅存储在移动设备上( IV将不被存储在设备上)。因此,每次用户需要登录时,将加密的密码和密钥发送到服务器,并存储IV,服务器使用刚刚发送的密钥和服务器上已有的IV对发送的加密密码和保存在数据库中的密码进行解密。
如果用户想要更改他们的密码,加密的密码,密钥和IV被再次生成,并被发送到旧的一个(密钥和加密的密码),如果它们匹配,这些值在服务器中更新,并发送通知到客户端更新它们。
所有这些事务也将在SSL隧道内发生。
你觉得这样安全吗?如果不是,为什么?从移动设备到服务器以安全方式加密/解密密码的任何其他选项?
致以问候。
发布于 2013-02-15 04:39:22
最好的方法是在发送数据之前在客户端对密码进行散列,然后发送散列。然后让服务器对该散列进行自己的散列,这样密码就永远不会离开客户端,也不能通过暴力强制存储的散列得到纯文本密码。
我在前面列出的KDF (pbkdf2、scrypt、bcrypt)非常耗时,所以您可能不想先在客户机上再在服务器上执行,除非安全性比正常情况下更重要。KDF用于防止有人暴力破解散列中的密码。这意味着如果存储用户散列的表被破坏,用户密码的明文仍然是安全的。例如,如果您在客户机上执行KDF,并在服务器上使用KDF生成的哈希的简单加盐MD5,那么用户的纯文本密码将是安全的,但能够访问存储的哈希(意味着服务器受到威胁)的人可能很容易以该用户身份登录。如果你的站点/应用是堆栈溢出,如果服务器本身已经被攻破,那么用户账户是否被攻陷可能无关紧要。另一方面,如果你是paypal,访问账户的人可以访问用户的银行帐户,这是他们无法通过简单地访问哈希表来实现的。在这种情况下,在客户端和服务器上执行KDF将是最佳的。
至于使用SSL,如果您有一种方法来验证服务器实际上就是您的服务器,并且没有进行MITM,那么使用SSL是很好的。如果其中任何一个遭到破坏,则以明文形式发送密码将使攻击者能够访问明文密码
https://stackoverflow.com/questions/14882519
复制相似问题