正確的方式來記錄和創建用戶帳戶

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地址。