1

次のユースケースがあります。

ユーザーは、ID、名、姓、および生年月日を検証フォームに入力することで、ビジネス アカウントを自己登録できます。ID は、ユーザーだけが事前に知っているものです。ユーザーは、すべての情報を照合するために 5 回試行します

検証の試行を保存するデータベースにいくつかのテーブルを維持することを計画しています

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

表 1 と 2 は一対多の関係にあります。これは、ロックされる前に、ユーザーが名、姓、および住所を 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