As an organization's IT security practices mature, it gets better at protecting its network perimeter systems: the patches get applied more regularly, the firewall rules become more restrictive, the OS gets locked-down more rigorously. Even at such companies, authentication systems often lag behind. If the employees, partners, customers, vendors need to remotely access an application with logon screen that requires a password, two things will often hold true:
1. The application will assist the user in remembering the password.
This may involve emailing the password to the user's email address. If you're an attacker, you will try gaining access to that inbox to retrieve the password.
The application may also present the user with a "secret question" picked by him or her in advance. Unfortunately, such questions often have easy-to-guess answers. Favorite color? Blue. Favorite month? March. It doesn't take many tries to go through likely answers to such questions. Even if it doesn't work for a particular user, it may work over a large population of targeted users. In many cases, answering such questions may not trigger the account lock-out mechanism.
Finally, the application may provide a different response to a valid username than to an invalid username. For instance, if the username and password are both incorrect, it might say "Access denied." But if the username is correct, it might say "Password incorrect."
Make sure your users recognize the importance of protecting access to their email boxes. Help them by protecting the email servers. Also, consider implementing complexity requirements for answers to secret questions or give users a few secret questions to chose from, but omit common questions such as those about color. Finally, don't provide too much information in response to a failure to logon successfully.
2. The user will select an easy to remember and easy-to-guess password.
There are too many passwords to remember. Of course, users will try to select those that are easy for them to remember. Much has been said about encouraging users to select hard-to-guess passwords, so I won't repeat the discussion here. Once concern to keep in mind is that if your selection requirements are too strict, or if the users need to change the password too often, they will still find a way to beat the system. They may write the passwords down or use the same password across multiple systems/sites/organizations.
Also, the use of default passwords plagues many environments. If possible, require that your users change the pre-assigned password after first logging on to the system, and make sure the default passwords you assign are difficult to guess.
Automatically locking an account after several failed logon attempts will address many of these concerns, but sometimes it's not a feasible option. We may be concerned about denying service to our customers or executives. Or we may not have the staff to deal with unlock-my-account requests. A nice compromise is often a mechanism that locks the account for a few minutes, then automatically unlocks it. This can slow down the attacker's guessing tactics, yet allow the legitimate user to login after a brief waiting period. Implementing CAPCHA to discern between human and non-human users of your site can be effective as well to discourage automated password guessing.
Include Remote Password Guessing in Your Assessments
If your security assessment procedures do not already include remote password guessing, consider adding this task. The steps that come to mind include:
Do you know of any lists that include passwords that actual non-IT users have used? We know of lists that include common passwords of IT staff, but we're looking for one that would apply to non-IT users. Not a dictionary file of potential passwords, but the words real users have used as passwords. If you know of such a list, let us know.
Update: A follow-up to this diary is available here as a separate note.
Aug 1st 2007
1 decade ago