A while back I was hunting for vulnerabilities in a web app's Forgot Password feature. On the first page you had to enter your username and email address. The second page asked a personal security question. That is quite weak. I recommend asking for at least 3 pieces of data on the first step. Asking for only two inputs, especially when they are username and email address, is not very secure. Username and email address are often related. If you know one, you might be able to guess the other. For example, the email address for user "jthomas" could be "jthomas@yahoo.com". I also recommend asking two personal security questions on the second page, not just one.
Anyway, one of the things I like to check is whether or not the account is locked after a certain number of failed attempts to answer the security question(s). This is an important defense against attackers who are trying to break in via the Forgot Password functionality. Sure enough, the message "account has been locked" appeared after I purposefully entered 3 wrong answers.
I was just about to make a note about this commendable practice, but something caught my eye. The input field was still there on the page. That's not something you normally see. Usually the application takes it away after a lockout occurs. So being a curious fellow, I proceeded to enter the correct answer to the question. Lo and behold the application sent me to the next page where I was allowed to reset the password on the account. Now that's an account lockout fail! I'm not sure why or how the developers created a lockout message without actually coding the lockout. Just another example of how difficult app security can be.
