Unsecured Login Hacks in Web Applications and How to Prevent Them - dummies

Unsecured Login Hacks in Web Applications and How to Prevent Them

By Kevin Beaver

Many websites require users to log in before they can do anything with the application. Surprisingly, these can be a great help to hackers. These login mechanisms often don’t handle incorrect user IDs or passwords gracefully. They often divulge too much information that an attacker can use to gather valid user IDs and passwords.

To test for unsecured login mechanisms, browse to your application and log in

  • Using an invalid user ID with a valid password

  • Using a valid user ID with an invalid password

  • Using an invalid user ID and invalid password

After you enter this information, the web application will probably respond with a message similar to Your user ID is invalid or Your password is invalid. The web application might return a generic error message, such as Your user ID and password combination is invalid and, at the same time, return different error codes in the URL for invalid user IDs and invalid passwords.


In either case, this is bad news because the application is telling you not only which parameter is invalid, but also which one is valid. This means that malicious attackers now know a good username or password — their workload has been cut in half! If they know the username, they can simply write a script to automate the password-cracking process, and vice versa.


You should also take your login testing to the next level by using a web login cracking tool, such as Brutus. Brutus is a very simple tool that can be used to crack both HTTP and form-based authentication mechanisms by using both dictionary and brute-force attacks.


As with any type of password testing, this can be a long and arduous task, and you stand the risk of locking out user accounts. Proceed with caution.

An alternative — and better maintained — tool for cracking web passwords is THC-Hydra.

Most commercial web vulnerability scanners have decent dictionary-based web password crackers but none can do true brute-force testing like Brutus can. Your password-cracking success is highly dependent on your dictionary lists. Here are some popular sites that house dictionary files and other miscellaneous word lists:

You might not need a password-cracking tool at all because many front-end web systems, such as storage management systems and IP video and physical access control systems, simply have the passwords that came on them. These default passwords are usually “password,” “admin,” or nothing at all. Some passwords are even embedded right in the login page’s source code.


You can implement the following countermeasures to prevent people from attacking weak login systems in your web applications:

  • Any login errors that are returned to the end user should be as generic as possible, saying something similar to Your user ID and password combination is invalid.

  • The application should never return error codes in the URL that differentiate between an invalid user ID and an invalid password.

    If a URL message must be returned, the application should keep it as generic as possible. Here’s an example:


    This URL message might not be convenient to the user, but it helps hide the mechanism and the behind-the-scenes actions from the attacker.

  • Use CAPTCHA (also reCAPTCHA) or web login forms to help prevent password-cracking attempts.

  • Employ an intruder lockout mechanism on your web server or within your web applications to lock user accounts after 10–15 failed login attempts. This chore can be handled via session tracking or via a third-party web application firewall add-on.

  • Check for and change any vendor default passwords to something that’s easy to remember yet difficult to crack.