Introduction to Broken Authentication
Broken authentication is a serious security issue and should be fixed as soon as possible. Although it has been widely documented for years, it still holds the second position in OWASP’s 2017 list of the 10 most critical web application security risks.
The Open Web Application Security Project (OWASP) is an open community dedicated to helping organizations develop, purchase, and maintain trusted applications and APIs. It has listed the most critical risks affecting web applications since 2004 – broken authentication first appeared on its list in 2004 and remains there today.
What is Broken Authentication?
Broken authentication usually occurs due to poor implementation of application features related to authentication and session management, allowing attackers to compromise passwords, keys, or session tokens, even going so far as to exploit other implementation flaws to temporarily or permanently assume users’ identities.
Broken types of authentication attacks
This kind of attack is quite easy to perform as cybercriminals can use several techniques such as variants of brute force attacks including dictionary based attacks or even credential stuffing (automatic injection of previously compromised/publicly available username/password pairs, not necessarily related to the current target, in order to fraudulently gain access to user accounts). Similarly, attackers also use automation tools to try to guess default administrator passwords.
Another way to exploit broken authentication is by using session management attacks. Because HTTP is a stateless protocol (ie, web servers respond to client requests without connecting to each other), it requires a third-party solution for session management. This kind of attack basically uses a mechanism to check and maintain state for the user interacting with it.
A simple example is the case of an unexpired session token vulnerability. For example, if the user accessing the application simply closes the browser, the session may not expire. This would allow an unauthorized party to use the same computer/browser to access the web application because the original user is still authenticated.
The prevalence of broken authentication is widespread, so it is important to consider its detection and exploitation, whether through manual means or automated tools (such as password lists and dictionary attacks), may not require advanced technical knowledge. This was the case with Aerticket, a Berlin-based ticket wholesaler, which exposed millions of passenger data, including names, credit card numbers and flight details.
A broken security vulnerability was found in an email sent to clients with a link to obtain and download a passenger’s itinerary confirmation. This link ended with an eight-digit number, and since the documents were not protected, simply changing the numbers would allow access to other passengers’ tickets, invoices, itineraries and credit card numbers. Since the bug has existed since 2011, it could theoretically have exposed data from 1.5 million bookings made over the years.
The impact of broken authentication is directly related to the context of the affected application, what information it stores, and whether attackers gained access to only a few accounts or administrator-level access that would compromise the entire system. Depending on the nature of the incident, this could be the basis for cases such as money laundering, Social Security fraud and identity theft, or disclosure of legally protected and highly sensitive information.
How can I prevent or fix broken authentication?
The first step to fixing this problem is to confirm that the application is indeed vulnerable. Using the right security controls that ensure user identity, authentication, and session management are critical defenses against authentication-related attacks.
For example, applications should be checked for:
- Lack of protection against brute force attacks (i.e. temporarily blocking an IP address that caused a high number of authentication errors in a short period of time)
- A poor password policy that allows weak or well-known passwords and the use of default administrator credentials (ie admin/admin or manager/manager)
- An insecure password recovery process such as using publicly available information (ie residential address, date of birth or guess answers) to confirm the user’s identity
- No use of multi-factor authentication (MFA)
- Exposing session IDs in the URL (i.e. URL rewriting)
- It will not rotate the session ID after successful login
- Poor session management (ie, failure to invalidate session IDs or authentication tokens during logout or after a period of inactivity)
Fixing the broken authentication problem is not difficult. Starting with the basics, no application should go live without changing all default passwords. Another great option is to use multi-factor authentication; this helps prevent authentication-related attacks, including brute force, credential stuffing, or the use of stolen credentials.
A good password policy is also important, allowing you to define an adequate level of password complexity and also to implement regular password rotation. This would help with brute force attacks and could also prevent the use of stolen credentials.
Password guessing attacks can also be prevented by restricting, blocking or increasingly delaying the originating IP address after failed login attempts. Whenever possible, failed login attempts should be logged and depending on the number of attempts from the same source, administrators should be notified to take further action.
As mentioned above, proper session management is also very important to avoid problems with broken authentication. The best option is to use a secure built-in server-side session manager that generates a new high-entropy random session ID upon login. Also, it’s important to note that the session ID should never appear in the URL; instead, they should be securely stored and discarded after the user logs out (based on an inactivity timeout).
User identity and authentication are among the most fundamental security concepts that hackers and cybercriminals have constantly (often successfully) tried to exploit. Broken authentication is easy to identify, and due to a combination of security-unaware developers and the widespread availability of automated tools, it’s quite easy to exploit. In other words, this issue cannot be ignored when the goal is to have a secure web application. There are several options for dealing with authentication-related attacks, from basic security controls such as password policy and account/IP lockout to advanced solutions such as MFA and session management controls.
One of the necessary protective steps is for professionals with responsibilities such as developing, managing or securing web applications to be aware of critical risks. This is where the InfoSec Institute can help.Their two-day OWASP Top Ten course offers a balanced mix of attention-grabbing lectures and hands-on secure coding activities. This Boot Camp was designed with the sole purpose of providing an overview of the ten most critical web application security risks as defined by OWASP. Click on the link above to see if the course is right for you.