SOUND – S for Secure Programming #2 | OWASP #2 | Broken Authentication

• Author
• Recent Posts

Atul Sharma

An extrovert by nature, Atul has been sharing his opinions and views on various social network platforms. He always had been thinking about having his own platform and here it is. Creative and tech-savvy Atul has a good sense of humor and when he is not programming or writing blogs or traveling, you can find him cooking, Netflixing or sleeping.

Latest posts by Atul Sharma (see all)

• RISE FROM THE ASHES – Sanjib Nandi - November 1, 2021
• साथ में मेरे दोस्त खड़े थे - August 1, 2021
• BenchmarkDotNet: Advanced Features - June 20, 2021

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” of the SOUND is NOT to be Security Expert but to understand all the security threats and their prevention.

What is Broken Authentication?

In this 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

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. Attacker may use various automation tools selenium, cURL or similar.

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

Prevention –

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 user leaves the system unattended and with new user starts using the system they get full access to the application and impersonate to be real user.

Prevention –

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 attacker to get access of the system.

Prevention –

1. Having a strong password.
2. Enforce 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. In case if user gives that URL to someone else, so this new user will be having access to the previous user data.

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

Prevention –

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

Scenario #5 – Weak Session/Token Management

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

Prevention –

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

Scenario #6 – Unsecure Transport

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

Prevention –

1. Always use https website or secured channel to login.
2. Password should be hashed and encrypted before sending to client.

Scenario #6 – Unsafe Storage of credentials

In many instances, plain storage of passwords can be very disastrous. In case of DB hack or inside information leak, it can lead to big issues, credential theft and later that can be used for credential stuffing.

Prevention –

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

With this, I hope now we have good understanding of broken Authentication. Share your feedback