If you have only one account with which you can log on to the web application, perform this test at the end of you test plan to avoid that you cannot continue your testing due to a locked account. Typically, to test the strength of lockout mechanisms, you will need access to an account that you are willing or can afford to lock. Evaluate the unlock mechanism’s resistance to unauthorized account unlocking.
Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing. Opportunities for further attacks: authenticated sections of a web application could contain vulnerabilities that are not present in the public section of the web application and could contain advanced functionality that is not available to public users. Administration panels: These sections are used by webmasters to manage (modify, delete, add) web application content, manage user provisioning, assign different privileges to the users, etc. Confidential information or data: Private sections of a web application could disclose confidential documents, users’ profile data, financial information, bank details, users’ relationships, etc. After a successful brute force attack, a malicious user could have access to: Without a strong lockout mechanism, the application may be susceptible to brute force attacks. when the user is presented with security questions during forgotten password mechanisms (see Testing for Weak security question/answer). 
Note that this test should cover all aspects of authentication where lockout mechanisms would be appropriate, e.g. Account lockout mechanisms require a balance between protecting accounts from unauthorized access and protecting users from being denied authorized access. Accounts are typically locked after 3 to 5 unsuccessful login attempts and can only be unlocked after a predetermined period of time, via a self-service unlock mechanism, or intervention by an administrator. Account lockout mechanisms are used to mitigate brute force password guessing attacks.
0 kommentar(er)
