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 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 case your login form detects too many failed login attempts.
Using default or simple passwords
During development, programmers often enter simple username/password combinations to allow easy log in and testing. And when time comes to publish to a production environment, the programmer forgets to remove the easy default login.
It’s only a matter of time before a malicious party discovers the 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.
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 all published code. Ensure that all testing code is stripped out when publishing your project to production.
Using a weak/broken system for 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 when a developer or administrator simply forgets 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 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.
Conclusion
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.
Consider having ComputerKick review your website for proper security and authentication.
