正确的方式来记录和创建用户帐户

Question

时登录蛮力攻击我们有以下的使用情况：

用户可以自行填写他们的ID，首先验证形式，姓氏注册一个企业帐号， DOB。 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和攻击，该怎么办？通过保持名字，姓氏和dob相同并猜测id？

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

编辑：这是一个带前端客户端的REST Api网址。所以Captcha可能无法保护API？

Answer 1

你是正确的，“秘密”ID增加了很少的安全价值，因为它是可以被蛮横强制的参数。如果攻击者知道第一个，最后一个，dob，那么他们可以遍历ID直到它被验证。

更好：锁定一个IP地址 s经过5个来自地址的无效尝试。这可以防止来自单个（或少数）计算机的无知类型的暴力行为。

最佳：为了防止从暴力破解在脚本方式，然后使用一个一个CAPTCHA僵尸网络或自动化系统是用于迫使人注册了传统的安全图案。

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

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