內容簡介
Adaptive Login Action 是一款自適應登入安全外掛，依據使用者 IP 位址的信任程度與登入歷史，動態調整驗證流程的嚴格度，在登入便利性與安全防護之間取得最佳平衡。
【主要功能】
• 零信任模式：依據靜態 IP 登入成功率自動調整驗證強度
• 動態 IP 模式：為行動裝置使用者提供簡化驗證流程
• 登入失敗時逐步加入額外安全驗證欄位（如 Secret Key）
• 統一錯誤訊息，不洩漏具體失敗原因以防止惡意探測
• 多次連續登入失敗後啟用限制性逾時鎖定機制
• 可與 New Users Monitor 外掛整合運作
外掛標籤
開發者團隊
原文外掛簡介
Adaptive Login Form: Adjusting compromise between Comfort and Paranoia.
Conception:
1. “Zero Trust Mode”
Recommended for small groups of regular Users with a Static IP Address.
Not recommended for Dynamic IP Addresses or Mobile Users.
If my current IP address is not marked as Dangerous since my last successful login, then there is no need to distrust me and force me to go through Quests to solve different types of Captchas.
In this case, the standard “Password” field is sufficient for one attempt.
But if the Attempt is unsuccessful, then we mark the IP address as Dangerous, and then it is possible and necessary to trick me (or the one who is trying to be me) with a more thorough login procedure.
There may be multilevel options. It doesn’t matter (this will be gradually added to the functionality). We are now talking about the General Principle.
Separate statistics are generated for each IP address and the ratio “Successful number of entries” / “Total number of entries” is determined. Depending on how close this parameter is to 100%, we can talk about the need for the Toughness of the Mistrust process.
This mechanism starts before the User enters his Login.
The more Unsuccessful Login attempts occur from a given IP Address, the more thoroughly it is checked.
Conversely, the Login procedure can be simplified as much as possible if there is no obvious reason.
“Dynamics IP Mode”
Recommended for mobile Users with a Dynamic IP Address.
Not recommended for Static IP Addresses.
If the User’s previous login was successful, their next authentication is performed using a simplified method.
Simply enter the correct password. However, only one attempt is allowed.
If the password was entered incorrectly, an additional security element is added to the login form: the “Secret Key” field.
Futured
Regardless of what kind of Authentication Error occurred, be it:
Invalid Username;
Invalid User Password;
Incorrectly specified additional security elements: “Secret Key” / Captcha / etc.
This will not be indicated in the error message. There will always be only one message: “Authentication Failed”.
Thus, we do not explicitly indicate to the potential Villain / Bot the reason for the denial of access. And the more such Reasons there are, the more complicated the Entry procedure becomes.
If multiple consecutive unsuccessful login attempts occur, a Restrictive Timeout may be activated for the given User.
Integration with “New Users Monitor”
