Common Vulnerabilities in Web Apps: Broken Authentication

Common Vulnerabilities in Web Apps: Broken Authentication

Web Application Risks: Broken Authentication

Welcome to the first of five posts addressing the typical vulnerabilities found in web applications. Here, Perspective Risk’s Senior Security Consultant Kai Stimpson looks at broken authentication and how to prevent it.
Neglecting to incorporate a robust authentication solution into your web app can lead to a threat actor gaining unauthorised access to it, compromising the confidentiality of your users’ data.

Want to check how good your organisation’s security is? Click here.

Common Pitfalls in Web App Authentication Solutions

When performing an in-depth penetration tests against web applications, these are the five pitfalls we regularly encounter:

Weak Password Policies

A password policy enforces the length, complexity and topology of a user’s password. The policy dictates the minimum and maximum characters allowed, which alphanumeric and non-alphanumeric characters are permitted, and whether or not passwords can be based on dictionary-style words or common phrases.

When there’s a failure to implement appropriate password strength controls in an application, it’s trivial for us to recover a user’s password. And if it’s easy for our Penetration Testers, it’s easy for cyber-criminals.

The absence of an account lockout policy

Applications which omit to temporarily disable or suspend an account after a set number of concurrent unsuccessful authentication attempts present adversaries with an opportunity. The neglect of such a control enables the continued guessing of passwords and greater probability of unauthorised access to a user account.

Additionally, when an application fails to detect an on-going brute force authentication attack, it’s common for an adversary to target multiple accounts with a number of passwords below the account lockout threshold.

Username Enumeration

Applications are often vulnerable to username enumeration. By supplying a self-registered, common or guessable username to a piece of functionality such as ‘forgotten password’ or ‘login’ and observing the application’s response, it’s usually trivial to derive a list of valid usernames that can be used in authentication and even spear phishing attacks.

Password Reuse

Passwords are often reused across several applications and systems. In such a scenario where a particular user account is compromised, the risks are multiplied.

Given that recent data breaches have been made public knowledge, it’s light work for threat actors to acquire a list of compromised user accounts and passwords and use them against targeted applications in an attempt to gain unauthorised access.

Applications that fail to inform a user during account creation not to reuse existing passwords are susceptible to this kind of attack.

Insecure storage of passwords

Even if a robust authentication solution – taking into consideration the above – is implemented, a common omission is the secure storage of passwords.

By exploiting other bugs and vulnerabilities found within an application, it can be straightforward for attackers to recover the encrypted users’ passwords from the associated database.

If strong encryption and hashing to store the data have not been enforced, cyber criminals can easily perform offline brute force authentication attacks to recover the plain text of passwords.

Seven Steps for Building a Robust Authentication Solution into your Web App 

To build a robust authentication solution into your application, here are seven steps to consider:

1. Don’t rely on a complex password policy alone. Inform users not to reuse a password that has been used on other applications or systems.

2. Implement the capability to log and detect on-going failed authentication attacks against multiple accounts. Block or prevent the source IP address of an attacker.

3. For sensitive web applications, consider two-factor authentication solutions such as Google Authenticator and SMS functionality.

4. Enforce a strong password policy. We recommend a minimum of 10 characters for users and 14 characters for high privilege level accounts. Lowercase, uppercase, numerical and special characters should be invoked and password topology observed to prevent users from choosing dictionary based words.

5. Apply an account lockout policy. Temporarily suspend or disable an account after 3 incorrect failed authentication attempts within a 5 minute observation window. Prompt users with an  additional authentication challenge to unlock their account when supplying their correct password.

6. Ensure your application does not respond with subtly different responses upon entering invalid / valid user names. To prevent automated attacks, implement CAPTCHA challenges on forms where user-supplied input is required.

7. Take care your applications are storing credentials appropriately with strong encryption and hashing algorithms utilising unique salts.

For further advice on the security of your web application, or for any cyber related matters, you are welcome to contact us today.

Want to know more? Get in touch with one of our experts today

Related Content

PRCON 2011

PRCON 2011

Whilst we are ardent supporters of maintaining a healthy balance between work and life and well awar...

Welcome to the Perspective Risk Blog

Welcome to the Perspective Risk Blog

The Perspective Risk blog has been created to provide information security resources to the penetrat...