1

我们有以下用例：

用户可以通过填写带有身份证、名字、姓氏和出生日期的验证表格来自行注册企业帐户。ID 是只有用户提前知道的东西。用户有 5 次尝试匹配他们的所有信息

我们计划在存储验证尝试的数据库中维护几个表

Table 1 columns: id, attempts
Table 2 columns: id, fname, lname, dob

表 1 和表 2 具有一对多的关系。下面是一个例子，如果用户在锁定之前尝试猜测名字、姓氏和 dob 5 次会发生什么。应用程序检查表 1 的尝试列，如果特定 id 为 5 或大于 5，则用户帐户（具有该特定 id）被视为锁定。

table 1
id   attempts
1234  5

table 2
id    fname   lname  dob
1234  john     doe   19900101
1234  jane     doe   19900101
1234  jason    doe   19900101
1234  john     dae   20010102
1234  roger    smith 19960101

上述方法的问题是我们只通过 id 跟踪失败的尝试。如果用户试图更改 id 并进行攻击怎么办？通过保持名字，姓氏和出生日期相同并猜测ID？

也许我需要重新考虑验证表的设计和我的方法来解决用户试图猜测 id 的问题？或者有没有更好的方法来思考这个问题？

编辑：这是一个带有前端客户端的 REST Api url。所以Captcha可能不会保护API？？

4

1 回答 1

0

您说得对，“秘密”ID 几乎没有增加安全价值，因为它是可以被暴力破解的参数。如果攻击者知道第一个，最后一个，dob，那么他们可以遍历 ID 直到它验证。

更好：在来自某个地址的 5 次无效尝试后锁定一个 IP地址。这可以防止来自单个（或少数）计算机的天真类型的暴力破解。

最佳：为了防止僵尸网络或自动化系统以脚本方式进行暴力破解，使用CAPTCHA是强制人工注册的传统安全模式。

如果 ID 是“秘密”，您还应该确保它足够长（例如，不仅仅是四位数字）。也许八个字母数字会为您愿意在这里容忍的风险级别提供足够的复杂性？取决于您的风险承受能力和系统/数据的敏感性。

编辑：为了解决 REST API 的安全问题......如果您只想允许从授权的 GUI 提交到 REST API，那么您可以使用 GUI 提交的随机数，然后由 REST 服务验证。（类似于 CSRF 保护。）如果您想允许从其他程序准备好提交到 API，这基本上是促进暴力攻击的秘诀。大多数主要的在线服务不提供这样的 API 用于注册。但是您仍然可以使用长/复杂的 ID 和锁定 IP 地址。

于 2016-07-13T00:46:56.387 回答