I hope that most of you are already well-known with the information about the authentication. But let us mention the basics at least. The authentication is the simplest of all security mechanisms employed within the web app. It is simple to explain-a user supplies the username and password, and then the application verifies that these items are correct. If they’re not correct, it doesn’t verify them.
Besides that, authentication protects the application against the malicious attacks. It does it by preventing unauthorized access.
But, let’s take a look how it functions in the real life. Actually, it is the weakest link and enables an attacker to gain the access. It may even happen when someone guesses the user’s password. Think you’re not that bad luck? I would rather take a look at the internet security tips and create a strong password.
Authentication Technologies
When implementing the authentication mechanisms we have a wide range of technologies which are to the web application developers. Those are HTML form-based authentication, multi-factor mechanisms, client SSL certificates, HTTP basic/digest authentication, NTLM or Kerberos and more.
Most commonly used authentication mechanism is HTML form-based. About 90% people over the web use it. Those are, of course, regular users. Banks use more complicated core mechanisms with more stages, for an example-PIN. It is important for the people who own the sensitive data to keep themselves safe as much as they can. If you’re running a business or you just think that the basic HTML form is not enough, you can read more about the cyber security tips. And I think you should.
Design Flaws in Authentication Mechanisms
We already talked about the bad password problem. You will read about the good and strong password at the internet security tips. So, what are the other flaws? Brute-forcible login. This is when someone guesses the password of the user.
Verbose failure messages. Sometimes you type your username or password wrong. If you’re not a total newbie in the tech’s world, you will know how to recognize if it’s the username that is wrong or is it the password. The hacker will know to recognize it too.
Vulnerable transmissions of credentials. When the app uses an unencrypted HTTP connection for transmitting the login credentials, the eavesdropper who is at that time suitably positioned on the network can intercept them. It may reside on the user’s local network, within the user’s ISP or within the ISP hosting the app and much more.
”Remember me” functionality. We all know what we are talking about here. It saves time, you don’t need to log in every time you need to enter your account etc. But I am pretty sure that you can imagine how dangerous it can be. Imagine an attacker who broke into your system, and every account you have is on the ”remember me” mode.
User impersonation functionality. There are some apps which implement the facility for the privileged user of the application to impersonate the other users in order to access data and carry out actions within their user context. We can explain in on the example. Let’s say that some banking app allows help desk operators to verbally authenticate a telephone user and then switch their app session into the user’s context to assist him/her. Sometimes it is implemented as a hidden function. So, if the app allows administrative users to be impersonated, any weakness in that logic can result in a vertical privilege escalation vulnerability.
Implementation Flaws in Authentication
It is important to know that even a well-designed app mechanism may be highly insecure due to mistakes made in its implementation. They lead to the information leakage or complete login bypassing. There are the defects in the multi-stage login mechanisms. There are some apps which use elaborate login mechanisms and those are the entry of a user name or password, the submission of a value which is displayed on a changing physical token and a challenge for a memorable word or specific digits from a PIN. They are designed to provide enhanced security over the simple model based mechanisms.
Prevent Bruce-Force Attacks
There are the measures that need to be enforced within all the various challenges that are implemented by the authentication function to prevent the authentication attacks that attempt to meet those challenges using the authentication. So, what does it include? The login itself, the functions to change the password, or to recover from a forgotten password situation if that happens etc.
So, the next is recommended to follow:
-When you use the unpredictable username and prevent its enumeration presents a significant obstacle to completely blind brute-attack and require the attacker to somehow discover more specific usernames before mounting its attack.
-Online banks (or some other security-critical applications) simply disable the account after a few situations where the login fails. Then, they require that the account owner take some various out-of-band steps reactivate that account. It may happen through telephoning a customer support and answering a series of security questions. But there are some disadvantages of this policy. It all allows the attacker to deny the service and to legitimate the users by repeatedly disabling their accounts and the cost of providing the account recovery service. There is a more balanced policy which is suitable for most security-aware apps, and it suspends the accounts for a short period of time (for about 30 minutes). It suspends it if the login was unsuccessful for about three times in a row. This practice massively slows down any password guessing attack, while also at the same time mitigating the risk of denial-of-service attacks. Besides that, it also reduces call center work.
-How to prevent the information leakage? The information leakage is leading to username enumeration. In that case, the app should never indicate that any specific account has been suspended. It should respond to any series of failed logins (such as three), even when the username was valid. The account needs to be suspended if those multiple failures occur. The user will try again later if he is the user that has the authority for that account. We talked about that earlier.
Prevent Misuse of the Account Recovery Function
We talked about the most security-critical applications, and we mentioned banking for an example. The account recovery of a forgotten password is handled out-of-band. But, most of the applications don’t want such kind of security. So, what to do?
-Well-designed password recovery mechanisms need to prevent the accounts from being compromised by the unauthorized party. In that case, it minimizes any disruption to legitimate users.
-”Hints” should never be used, they mainly help for the attacker to trawl for accounts that have the obvious hints set.
So, we’ve learned a lot today. Hope that this topic helped you to learn more about the authentication process and the attack that happens through it. Always remember that the authentication functions are the most prominent target in the typical app’s attack surface. They can reach by unprivileged, anonymous user. Once they’re broken, they grant the access to protected functionality and the sensitive data. Lying at the core of the security mechanisms that an app employs to defend itself and are the front line of defense against unauthorized access.