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:

• Identify publicly-accessible services/applications that request username/password credentials and attempt bypassing them via manual guessing. Keep an eye out for account lock-out mechanisms.
• Query Google and examine your public website to identify possible usernames. (The Backtrack CD has some nice tools for that.)
• Compile a list of possible passwords the users might use, accounting for your organization's location, name, and industry-specific terminology. Add common names and words like "passsword" to the list. I find that having a short, but intelligently-crafted list is more effective than using a 100KB dictionary file (the long file often takes too long to cycle through remotely).
• After trying the manual route, make use of an automated password guessing tool to see whether it can guess logon credentials using the short password list you put together. Hydra is an excellent tool for this task. It's free, fast, and effective, even though it's poorly documented. (Anyone feels like writing a comprehensive guide to using Hydra, or pointing us to one that already exists?) Hydra is included on the above-mentioned Backtrack CD, and supports most of the protocols you're likely to encounter in the field.

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.

 -- Lenny

Lenny Zeltser
ISC Handler on Duty
www.zeltser.com