Broken authentication is often the result of weaknesses in access controls and session management. Some common weaknesses include weak password policies, unencrypted traffic, and poor logout mechanisms and timeouts.
Factors of authentication
Before we can talk about weak passwords, we should mention factors of authentication. A password, for example, is one kind of authentication factor.
When an application tries to authenticate your identity, it usually uses a combination of three factors: Knowledge, Possession, and Physical (Something you Know or You have or You are). It can’t use just one factor because one isn’t strong enough on its own.
The knowledge factor is something you know, like your password, but it can’t be relied on to protect your account on its own because it can be guessed by someone who knows you, or found if you wrote it down.
The possession factor is something you have, like a key card or ID. These items can be lost or stolen by someone who wants to impersonate you.
And the physical factor is what you are, like your fingerprints. This factor is expensive to use, can have problems with accuracy, and is difficult to replace. Since your physical factors don’t typically change, and you can’t easily replace them, this factor can be problematic.
Let’s look at an example. ‘Vijay Kumar’ works at a company called CRCE Inc. that forces all their employees to reset their passwords every 15 days. After years of working at CRCE Inc., Vijay resets his password and jots it down in a notebook just in case he forgets it.
The next day, Vijay finds that someone has logged into his computer and changed his background. Vijay’s co-worker, Emily, saw him write down his password and was able to log into his account.
We can see that because CRCE Inc. only uses single factor authentication for their systems, finding someone’s password is enough to bypass authentication entirely and cause mischief.
Weak password change control and practices
Forgotten passwords can actually be a major risk for user account authentication. Even though many users and businesses rely on this feature, it isn’t always secure. Attackers can actually benefit from weak “forgot username” or “forgot password” features on an otherwise secure website.
In this example, an attacker uses a “Forgot Password” page and enters the username of their target. The “Forgot Password” page then sends a 6-digit secret code to the account owner that expires in 15 minutes.
Even though the feature makes sure the secret code expires, there are no limits on the number of attempts someone can enter the code. The attacker could easily brute force the code by entering all possibilities for the 6 digits within those 15 minutes.
About HTTP and cookies
HTTP is the language we use to talk on the web and is important to understand before we discuss session management. There are different versions of HTTP, but in general, you can think of HTTP as working through requests and responses.
HTTP requests contain a lot of information that helps applications track state and user session management. Each HTTP request contains a goldmine of information that can be traced like a trail of breadcrumbs if unprotected.
This information is stored in cookies on the client-side, and in session IDs, also called session tokens, on the server-side. Session cookies, one of many types of cookies, contain a session ID.
Session cookies and session IDs have the same goal, and help to keep state. They store information about your interaction with a web site, but cookies are stored in your browser, whereas a session ID is a string of random numbers and letters that must be sent on every request. Cookies don’t expire until you close the browser, but session IDs can time out.
Session IDs are a representation of the user and their actions on the web. For instance, session IDs can have data about whether a user is logged in, has items in a shopping cart, or has timed-out their session. In fact, the only defining feature of what identifies a user on the web is their session ID.
Insecure Session Management
This brings us to insecure session management. As we mentioned, when you log in to a web site, you’re assigned a session ID. This becomes associated with your browser and allows you to navigate the web site without having to enter your password on each page. Your session ID identifies and represents you on the web.
Unfortunately, many sites only securely protect a user’s credentials, and not the session ID. If a hacker were able to get someone’s session ID, they would be able to log in and impersonate that user before the session timed out.
Hackers could guess or predict Which session IDs are active to impersonate another user by using their assigned ID. They could even steal IDs if the server were sending out session IDs under unencrypted traffic.
Session hijacking
Unencrypted or clear-text traffic is any web traffic sent through an insecure channel that isn’t encrypted. Clear-text traffic is highly vulnerable to man-in-themiddle attacks because it isn’t protected and can be read by anyone who intercepts it using various techniques.
If a hacker comes along and intercepts unencrypted web traffic, then they could steal session ID and impersonate a user. Remember, the session ID is the only thing that identifies users, so if a hacker steals this, the webserver can no longer tell the difference between a legitimate user and the hacker.
We all know about insecure WiFi and using an unsecured public WiFi connection, Let’s look at an example of how session hijacking can work.
‘Vijay Kumar’ is a sales executive and browsing his recent sales transactions on a local coffee shop’s free wireless connection. Vijay’s connection on the public WiFi is over HTTP, which doesn’t use encryption.
Meanwhile, a mischievous computer expert is also sitting at the coffee shop and intercept Vijay’s network traffic using special tools and successfully retrieve its session ID from unencrypted network traffic.
The hacker simply copies the session ID into his/her own browser, and since Vijay has already authenticated, he is able to log in. Since, they are both using the same session ID, as long as Vijay doesn’t log out, the hacker will have access using the same session ID.
Session fixation
Sessions can also be vulnerable to session fixation attacks. This happens when an attacker fixes, or forces, a session they already know onto an unsuspecting user. If the user authenticates with the fixed session, the attacker can then use it with all of the same privileges as that user.
For example, rather than attempting to hijack a user’s session, an attacker can purposely expose a link with their session identifier to a known administrator. When the administrator logs in, the session becomes active with administrator privileges.
However, the attacker also has access to the fixed session ID, so the attacker’s session is also active.
Countermeasures against Broken Authentication
Use 2 factors of authentication
As we learned about factors of authentication in the above sections of this article and by combining different factors of authentication, the web application can overcome from unique weaknesses.
For example, the Administrator can combine knowledge with possession-based authentication to overcome a weakness in a password being guessed or a token being lost.
Using two different factors of authentication together is called 2-factor authentication, and many organizations are improving their security by using two or more factors for their authentication.
Strengthen forgot password controls
While implementing the forgot password feature, considering some of the above-mentioned countermeasures can help by adding layers of defense against hackers.
Treat the forgot password feature with the same importance as authentication by adding aspects such as complexity to any secret challenges or even 2 Factor Authentication.
Session timeout
Setting a reasonable session timeout can help ensure that attackers who steal session IDs have a limited timeframe to use them in.
A session timeout can depend on the security profile of the application. 5-10 minutes may be reasonable, but the organization should decide based on risk.
Another option is to implement an absolute timeout so that even if a session is stolen, forcing a logoff after a fixed time ensures that all sessions eventually expire.
Finally, before any new user session is authorized, any existing session IDs should be invalidated. This prevents session fixation.
Network encryption
Encrypting traffic using SSLJTLS is another way to protect user information and is becoming more common. In a previous example, we saw how a hacker could intercept web traffic and steal session data, but if traffic is encrypted, this is no longer possible, or at least very difficult.
Encryption is a good first defense against session hijacking.
Account lockout
Finally, account lockout is a good defense against password attacks. Limiting the number of attempts users have to enter their passwords can help ensure that hackers can’t use brute force techniques by trying passwords until they gain access.
However, the account lockout can cause problems. Attackers cause a denial of service if they try to lock out all of the accounts of a system. In this case, consider using a policy that increasingly delays the time between password attempts each time they fail to enter incorrectly, rather than locking out the account.
Key Takeaway from this article
- SessionlDs are how users are identified in web applications and so disclosing this sessionID is dangerous as users can be impersonated.
- Encryption is a good first defense against traffic sniffing and can help protect clear-text traffic on the Internet.
- Account lockouts or increasing time delays can help deter hackers from automated attacks against your web application.
- Implementing session timeouts can also help ensure that if a session is stolen, by the time it is used it has already expired.
