Web Site Vulnerabilities – Broken Authentication

By Chris David and Franklin Aguilar

Allowing brute force attacks, permitting weak passwords, shipping a product with default passwords (like admin/password) or using weak credential recovery… These are all examples of Broken Authentication. Rated as the second most critical security risk to web applications, Broken Authentication can allow attackers to gain access to your important business data.

The level of the attack depends on your application and what data you track. For basic websites, attackers could use Broken Authentication to take over and replace your web pages, to damage your business reputation. For mission-critical and financial applications, attackers could compromise your entire business, download your customer information and engage in fraud and identity theft.

Let’s review some examples and then recommend possible mitigations that you or your web developer can follow on your own website.

Allowing brute force attacks

Because of past data breaches, hackers now have access to vast databases of usernames and passwords. With a list of thousands of usernames/passwords, a hacker can write a program or script (or use one that someone else has developed) and perform an automated attack on your website. The attacking program will send thousands of possible credentials, to see which, if any, are valid. Eventually, the attacker might get lucky and be able to log in. We call this type of attack brute force, or  “credential stuffing”.

Mitigation: Design your web applications and login forms with brute force attacks in mind. Limit failed login attempts, and add a delay in the case of multiple login failures. Consider notifying an administrator in the case that your login form detects too many failed login attempts.

Using default or simple passwords

Many times during development, programmers enter simple username/password combinations to allow easy log in and testing. And when the project/site is published to a production environment, the programmer might forget to remove that default login. It’s only a matter of time before a malicious party discovers the default or easy password and gains access to the system.

Mitigation: Enforce strong password policies for all user accounts in the database. Enforce password complexity, even during development. Review all accounts, especially admin accounts, during deployment and publishing.

Exposing plain text passwords or session IDs

Depending on the application, a developer might output credentials or session IDs to the screen, or note them in code comments, for testing, etc. Doing so can make a developer’s life easier when writing and debugging new code. Or consider that a login session ID might be left visible/unencrypted in scripts or URLs. And when the pressure is on and deadlines are looming, the developer might forget to remove the testing code/comments/scripts. By reviewing the script from a site, or decompiling application code, a hacker can discover the credentials or session IDs, and then log in to the application.

Mitigation: Separate your development and production environments. Make sure someone reviews code that is published. Ensure that all testing code is stripped out when publishing your project to production.

Using a weak/broken system of credential recovery

A common scenario allows users to recover their account information, in case of a forgotten password. The user will go to a form on your website/application, enter some additional authenticating information and then receive a new password. If this system is broken or poorly thought-out, an attacker could gain access to account passwords.

Mitigation: Use multi-factor authentication for your application, including email or SMS messages. This will ensure that a user has access to “multiple factors” that identify their account, instead of just a username/information combination.

Allowing a user to view sensitive data without entering a password

Believe it or not, one of the most common examples of Broken Authentication is that a developer or administrator simply forgot to secure the information. The most well-known case: In 2019, a former software engineer gained access to a huge cache of social security numbers and Capital One bank account numbers because the data server holding the information was not password-protected.

Mitigation: Periodically review your websites and data stores for correct ownership and authentication. Just as with Sensitive Data Exposure, ensure that sensitive customer information is encrypted at rest.

What To Remember

Broken Authentication is most often the result of sloppy development and management techniques. If you are doing the work yourself, double check all your code when deploying to your production servers. If you hired a team of developers, make sure that at least two staff review all code before going into production. Perform a periodic cybersecurity review. Have management systems in place to make sure that all databases and customer data are secure.

For companies in the Colorado Springs or Front Range area, consider having Overkick take a look at your website for proper security and authentication.

Broken Authentication is an open door to your customer data!
Share on facebook
Share on pocket
Share on linkedin
Share on stumbleupon
Share on mix
Share on email

Comments