Hi,
Thanks for details and my inline comments
> If value is 0, account should not be locked, so in above case we need to throw error invalid username, password if user tries with invalid password, please correct me if I'm wrong
As stated in other posts, security best practices prefer you do not have specific messages that indicate which portion of the credentials is incorrect. Simply state "Invalid credentials" in the response so a potential attacker does not get hints as to what portion is correct. This also includes cases where the username and password are valid, but the account is locked; still simply state "Invalid credentials" to prevent a potential attacker from inferring a particular state.
Mani: Agreed and giving message as Invalid username or password, User account won't get locked and he can try any number of incorrect password with above settings, please confirm> What is the difference between AccountLockoutCounterResetAfter, AccountLockoutDuration attributes?
AccountLockoutCounterResetAfter: This is used to control when to reset the internal "failed login" counter for an account.
AccountLockoutDuration: This is used to control how long an account is locked once it hits the lockout threshold.
So, for example, let's assume there is an account with the username "admin" and password is "password" with the configuration you have above...
Scenario 1: User attempts to log into the service and provides "admin" was the username and "test" as the password twice. At this point the internal failed login counter is at 2. 10 seconds elapse with no further login attempts; the internal counter is reset back to 0. User attempts to log into the service and provides "admin" was the username and "test" as the password twice (again). At this point the internal failed login counter is at 2 (again). Even though the user has four consecutive failed login attempts, because of that 10 second delay between attempts 2 and 3, the failed login counter was reset. The user attempts to log into the service with "admin" and "password", and the login request is successful.
Scenario 2: User attempts to log into the service and provides "admin" was the username and "test" as the password three times. Because we did not reach the 10 second reset timer, the account is now locked for 20 seconds. Even though the failed login counter clears after 10 seconds, the account is still in the locked state for the full duration of the 20 seconds; the locked state is independent of the internal failed login counter.
Mani: Got your point. AccountLockoutCounterResetAfter will be useful in Scenario 1 and for Scenario 2 to AccountLockoutCounter can start counting after 20 seconds and it will be in 0 only between 10 to 20 seconds, eventhough user tried any number of invalid login attempts(between 10 to 20 seconds) since user account is already locked.
Thanks,
Mani