保护网络应用程序[关闭]

Question

我正在开发一个同时具有 Web 和移动 Java 界面的应用程序。 Web 只是一个“旁观者”，因此不能以任何方式改变数据库。另一方面，java 接口可以（而且经常这样做）。我不想使用自签名证书，所以我想出了这个解决方案。我想问的是它是否可以被认为是安全的，或者是否有更好、更有效的方法来做到这一点。我是一个有点偏执的人，所以请考虑到这一点。

当安卓设备注册自己时，我将密码保存为 sha256(pass + pass)。这是唯一一次设备必须以纯文本形式发送密码。这个函数产生我称之为 [hash] 的东西，并将存储在我的数据库中。

登录时，设备会发送 sha256([hash] + unixTime) 创建的新哈希以及 unixTime。我需要使用 [hash]，否则我将无法验证密码。服务器将尝试重现该功能的产品，如果成功，则验证用户。发送的 unixTime 之后会被插入到数据库中，所以我也可以检查一下，这个时间是否还没有被使用（如果 unixTime 小于或等于保存，因此伪造/来自过去，我可以安全地将其丢弃为无效）

同样，所有其他需要身份验证的数据包都将以这种方式进行验证（因此每个数据包 = 新哈希）

注意：所有哈希都转换为十六进制，只是为了节省一些位。

Answer 1

我想问的是它是否可以被认为是安全的，或者是否有更好、更有效的方法来做到这一点。

“可以被认为是安全的”要求并不高。我认为它可以防止未经授权的登录，只要攻击者无权访问设备、网络或数据库。在这种情况下，以明文形式传输和存储密码的简单系统也是安全的。考虑到特定的安全目标和威胁模型会更有意义。

以下是此设计的几个关键问题：

1. 如果攻击者可以从数据库中获取哈希值，他们可以在不知道密码的情况下通过计算sha256([hash] + unixTime) 登录。
2. 控制网络的攻击者可以拦截sha256([hash] + unixTime), unixTime 对并逐字使用它。 SSL 将阻止此类攻击者获取这些值。
3. 如果攻击者可以从数据库中获取哈希，他们可以快速尝试哈希密码并查看哪些用户的哈希匹配。加盐哈希可以防止这种情况发生。

Answer 2

听起来除了说您不想使用自签名证书之外，您还反对使用 https，即使它是由受信任的证书颁发机构颁发的证书；是这样吗？如果是这样，为什么？即使是一次明文密码也是一个重大漏洞；对于在您的网络流量经过的机器上运行数据包捕获软件的任何人来说，明文密码都是免费游戏，更不用说如果您选择了错误的 http 方法，那么这些密码肯定会最终出现在任何代理的日志中.

我还建议您至少妥善保存密码。如果您的数据库被恶意方检索，不这样做会导致许多安全漏洞；例如，预先生成的彩虹表攻击是可行的，并且由于哈希匹配，攻击者能够轻松识别哪些用户具有相同的密码。有一篇很棒的 Owasp 文章，介绍了您应该注意的关键事项 here。

是否可以选择使用 oauth 之类的解决方案？我最近在一个移动应用程序中实现了 Google OAuth，它与 ssl 结合起来非常简单。无需重新发明轮子，尤其是在加密和用户身份验证方面；）