OWASP : BROKEN AUTHENTICATION attacks

When authentication functions associated with the application aren’t implemented correctly, it allows hackers to compromise passwords or session ID’s or to take advantage of other implementation flaws using other users credentials, then the vulnerability is called as Broken authentication. Once an account is hijacked, the attacker has the flexibility to try and do anything the account holder has permission to do, which may lead to serious consequences affecting the company’s viability as an entire. An attacker only needs access to some accounts or simply one admin account to compromise the application. Depending on the aim of the application, damage can range from fraud to the leaking of sensitive personal information.

In Broken Authentication, whenever a user login into its account, a session id is being created, which session id is allowed to that particular account only. To give easy accessibility to its users to log in from anywhere, sensitive Data is often saved on cloud applications. This accessible-anywhere feature is creating challenges for traditional methods to secure various potential vulnerability points. Now if the web application is crafted securely in terms of Authentication, then it’s well and good but just in case if it’s not then the attacker may use several under given techniques.

Broken authentication could be a broad category with various other security flaws bundled as a full. Any security flaw generated because of a mistake within the implementation of authentication and session management falls under broken authentication. With such diversity, it’s difficult to seek out common grounds between these vulnerabilities. Broken authentication occurs when an application’s authentication and session management are implemented incorrectly, which subsequently allows attackers to achieve access to a user’s session either temporarily or permanently. Attackers can detect broken authentication by manual methods and to exploit it they use automated tools.

Attackers use following attacks to exploit this vulnerability :

Credential Stuffing : Credential stuffing is a sort of brute force attack that takes advantage of our struggle to pick unique passwords across our various accounts. Cyber criminals use the compromised credentials to induce access to other online accounts. This is often hardly surprising after you consider that the typical American internet user has 150 online accounts requiring a password. Yet many people have had account credentials compromised as a part of a data breach.

Attackers implementing credential stuffing will use these compromised credentials on several other websites to check if the login details are re-used and they often are getting re-used. These kinds of attacks will be done at scale by bots, resulting in the next likelihood of those attacks affecting your organization.

Steps of the attack -

• Attacker acquires credentials from an internet site breach or password dump site.
• Automated tools are used to test credentials across a spread of various sites.
• When a successful login occurs, the attacker harvests the sensitive data or executes the subsequent stage of their breach.

Password Spraying : Password Spraying is another sort of brute-force attack. Under this attack, users using the foremost common passwords fall prey to attackers. These most frequently used passwords should match the complexity policy of the domain. So, rather than trying multiple passwords for the identical account holder, the attacker uses the commonly used passwords for various users.

Steps of the attack -

• Attacker uses a list of commonly used passwords that match the complexity policy of the domain.
• Instead of trying multiple passwords for one user, the attacker uses the identical common password across many alternative accounts which helps avoid detection.
• Once the attacker encounters a successful login, the attacker harvests the sensitive data or executes the following stage of their breach.

Unhashed Passwords : Hashing is the process of converting a given key into another unidentifiable value. A hash function is employed to come up with the new value according to a mathematical algorithm. a decent hash function uses a one-way hashing algorithm, or in other words, the hash can not be converted into the first key. If a website doesn’t use hashing what an attacker does is, an attacker can intercept the user request as both of them are on the identical network. Using the intercepted request they can clearly see the text submission of passwords that users submit on the web site. Using this system users can lose his Account Authorization & Confidentiality.

Misconfigured Session Timeouts : Session timeout is an event occurring when a user doesn’t perform any action on a web site during a long interval. This very event, on the server side, changes the status of the user session to ‘invalid’ and sends an instruction to the web server to destroy it. During this scenario a user logs out of the account and an attacker has the cookie of that user. Using the cookie, an attacker can still have access to the account. Using this kind of loophole Cookie Tampering, Session hijacking and other attacks will be chained into one single loophole, which is additionally called chaining of bugs. Such type bugs are remarked as Misconfigured Session Timeout.

How to avoid falling for Broken Authentication Attacks :

• If possible, implement multi-factor authentication (MFA) to stop automated, credential stuffing, brute force, and stolen credential reuse attacks.
• Do not set up an account with any default credentials, mainly for admin users.
• Implement weak-password checks, like testing new or changed passwords against an inventory of the highest 10000 worst passwords.
• Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or any other attack is detected.
• Use a server-side, secure, built-in session manager that generates a brand new random session ID with high entropy after login. Session IDs should not be within the URL, it should be securely stored and invalidated after logout, idle, and absolute timeouts.