保护Web应用程序

Question

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

当Android设备注册时，我将pasword保存为 sha256（传递+传递）。这是设备必须以纯文本形式发送密码的唯一时间。这个函数产生我称之为 [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方法，那么这些密码肯定会最终坐在任何代理的日志中。

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

使用像oauth这样的解决方案吗？我最近在移动应用程序中实现了Google OAuth，与ssl结合使用非常简单。无需重新发明轮子，特别是在加密和用户身份验证时;）