All About OWASP #2 - Broken Authentication

After covering the Injection Attack in the first part of secure programming from SOUND Programming Methodology, now, we will be covering Broken Authentication.

The objective of “S” in "SOUND" is not to be a security expert but to understand all the security threats and their prevention.

What is Broken Authentication?

In a "Broken Authentication" situation, the attacker takes control of the system using flawed authentication mechanism. There are many scenarios where broken authentication can be used to intrude the system.

Scenario #1 – Credentials Stuffing

An attacker may use the combination of credentials stolen during any previous theft. They may use this combination to impersonate any user and get fraudulent access to the system. The attacker may use various automation tools like Selenium, cURL, or something similar to these.

As per some reports, during the second half of 2018, 28 billion credential stuffing attacks were reported. In 2016, approximately 500 million Yahoo accounts were compromised.


  1. Having 2-Factor Authentication
  2. Not using the same credentials again and again.
  3. Not to use the same credentials on various portals.

Scenario #2 – Session Timeout is NOT set up properly

In this case, when a user leaves the system unattended and a new user starts using the system, they get full access to the application and impersonate to be the actual user.


  1. Set proper time out for session expiry.
  2. Idle time to spontaneously kill the session.

Scenario #3 – Weak Password

Easy and default password may help the attackers to get access to the system.


  1. Have a strong password.
  2. Enforce the password change periodically.
  3. Impose a complex and different password from other systems.

Scenario #4 – URL rewriting

When any website rewrites the URL and appends the session id to it, if the user gives that URL to someone else, the new user will be having access to the previous user data.

This may happen when an authenticated user comes across an offer and wants to share the offer with his/her friend to avail that. Now, that friend may have access to all his/her account details.

  1. Session ID should not be used in the URL.
  2. Use of tokens and validation at the server side must be encouraged.

Scenario #5 – Weak Session/Token Management

In this scenario, the attacker manipulates the session id or token stored in the client machine (Cookies/ Local Storage/ Session Storage).


  1. Token validation should be implemented at the server level for the prevention of tempering the token.
  2. Don’t store sensitive information in the token. For example – JWT token information can read easily.

Scenario #6 – Unsecured Transport

Here, credentials are transmitted over unencrypted and unsecured wire and an attacker may intercept to capture credentials and other sensitive information.


  1. Always use HTTPS websites or secured channel to log in.
  2. The password should be hashed and encrypted before sending to the client.

Scenario #7 – Unsafe storage of credentials


  1. Passwords should be hashed and/or encrypted.
  2. The password should NEVER be hardcoded in the source code.
  3. Decryption key should be kept safe.

With these tips, I hope now we have a good understanding of Broken Authentication and its prevention. If you liked this article, please don't forget to share your feedback.

Similar Articles