Proper way to document and log brute force attacks when creating a user account

Question

We have the following use case:

Users can self register for a business account by filling a validation form with their id,First, last name and DOB. ID is something that only the user knows ahead of time. Users have 5 attempts to match all of their information

We are planning to maintain a couple of tables in a database in which we store the validation attempts

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

Table 1 and 2 have a one-many relationship. Here's an example of what happens if user tries to guess the firstname, last name and dob 5 times before its locked. The application checks table 1's attempts column and if it's 5 or more than 5 for a specific id, the user account (with that specific id) is treated as locked.

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

The problem with the above approach is that we are only tracking the failed attempts by id. What if user tries to change the id and attack? by keeping the first name, last name and dob the same and guessing the id?

Maybe I need to rethink the validation table design and my approach to solve the problem of user trying to guess id?? Or is there a better way to think about this problem?

Edit: This is a REST Api url with a front-end client. So Captcha might not protect the API??

Answer 1

You're correct that the "secret" ID adds little security value, since it is the parameter that can be brute-forced. If an attacker knows the first, last, dob, then they can just iterate through IDs until it validates.

Better: lockout an IP address after 5 invalid attempts coming from an address. That prevents naive types of brute-forcing from a single (or few) computers.

Best: To prevent a bot-net or automated system from brute forcing in a scripted fashion, then using a CAPTCHA is the traditional security pattern for forcing human registration.

If ID is the "secret," you should also make sure it is long enough (not just four digits, for instance). Maybe eight alphanumeric would give enough complexity for the risk level you're willing to tolerate here? Depends on your risk tolerance and the sensitivity of the system/data.

EDIT: To address securing a REST API... If you want to only permit submissions to the rest API from authorized GUIs, then you could use a nonce submitted by the GUI, which is then validated by the REST service. (Similar to CSRF protection.) If you want to permit ready submission to the API from other programs, that's basically a recipe for facilitating brute force attacks. Most major online services do not provide an API like that for registration. But you could still use a long/complex ID and lockout IP addresses.