05-24-2012, 12:42 PM
The design of the account lockout functionality seems to be a little naive and in the worst case, exposes the application to potential denial of service, as well as potential exposure of valid accounts.
Since at least one account has a fixed username (admin) created at install time, there's a high probability that account will be in use and will be an admin account - possibly the only admin account.
I suggest a more flexible approach that will maintain security with reduced potential for DoS:
Limit attempts per IP and per session cookie to 5 unsuccessful attempts in 15 minutes. After 5 attempts, further attempts simply fail with the same error as they would with invalid username or password.
Limit attempts per username (and track this even if the username isn't valid so that it's not possible to infer which usernames correspond to accounts). Rather than locking the account out after 5 attempts, display a CAPTCHA before the user can log in. After 20 attempts, require a token code to be sent to the user's email for each attempt.
Since at least one account has a fixed username (admin) created at install time, there's a high probability that account will be in use and will be an admin account - possibly the only admin account.
I suggest a more flexible approach that will maintain security with reduced potential for DoS:
Limit attempts per IP and per session cookie to 5 unsuccessful attempts in 15 minutes. After 5 attempts, further attempts simply fail with the same error as they would with invalid username or password.
Limit attempts per username (and track this even if the username isn't valid so that it's not possible to infer which usernames correspond to accounts). Rather than locking the account out after 5 attempts, display a CAPTCHA before the user can log in. After 20 attempts, require a token code to be sent to the user's email for each attempt.