Hey, hey... Programmer, this is another article for you! The second part of the article on design patterns. Get to know Adapter and Memento.
Hello, today as Innokrea, we would like to provide you with some informative knowledge about what authentication is, what the second factor is, and what options we have for confirming a user’s identity. In the end, we will explain what session hijacking is. If you’re interested, we invite you to read on!
Entities and User Identity
Let’s start by considering how large companies manage user identities and what it actually entails. Managing user identities is a crucial element of overall company security. At a large scale, where we have thousands or even hundreds of thousands of user accounts, we often use specialized software like Windows Server AD, or we have a dedicated component in our application that carries out the authentication process.
But what is user identity exactly? It’s a set of characteristics about a specific entity. In this case, entities can be both working individuals and devices that the company uses. The concept of identity is often used in the context of people, and the characteristics are simply attributes of a particular person, such as their name, surname, age, or job role. These attributes can also be categorized as variable or constant, for example, eye color or fingerprint are constant, while surname or job role can vary. In summary, it’s important to know that both the concept of identity and the concept of entity can be generalized and not necessarily refer to a human being.
Authentication vs. Authorization
Now that we’ve clarified what identity and entity mean, it’s a good time to take the next step and define authentication.
Authentication is the process of confirming/validating the identity of a specific entity before granting it access to resources. Resources in this context can be parts of the network infrastructure, files, or even a printer. Authorization, on the other hand, is the process of granting a particular resource to a user who has authenticated themselves in our application or system.
In the most common scenario, a user employs certain knowledge, attributes, or items to prove their identity in the authentication process. The fundamental factors users can use for authentication fall into three categories:
- Something the user knows – the most classic form of authentication, such as a password or PIN that the user remembers.
- Something the user possesses – a physical item, like a certificate and its key, allowing them to prove their identity. If they possess a trusted certificate, for instance in a smart card or a U2F key with personalized keys, it proves their identity through possession.
- Something the user is – for example, fingerprints, facial recognition, voice, or retina recognition. These types of authentication (except retina) are often used in mobile devices.
Additional authentication factors can be based on behaviors, typing speed on the keyboard, or location, for example. It’s important to note that most, if not all, of the mentioned categories and authentication factors can be spoofed. Someone could extract a password from a user through a phishing attack, a smartcard could be stolen, and a voice could be impersonated using artificial intelligence. You could even use AI algorithms to generate a voice that attempts a phishing attack on an employee over the phone.
Two-Factor Authentication
To enhance the security of computer systems or applications, two-factor or multi-factor authentication is often employed. However, it’s important that each factor comes from a different category mentioned above, for example:
- A bank user, after entering a password, must also provide a code received via SMS (something the user knows and something the user possesses).
- A messaging app user, upon logging in with a password, must also provide a code generated by the Google Authenticator app on their phone, a Time-based One-time Password (something the user knows and something the user possesses).
- An employee entering the office must tap their card on a reader and also be verified by a facial recognition system or the on-site security personnel (something the user possesses and something the user is).
Of course, each of the mentioned two-factor authentication methods can be attacked in some way, although some methods can be considered much safer than others.
Example Attack Scenario
The scenario presented first, with a password plus a second factor using SMS, is not entirely secure. Attacks like SIM Swap are known, and they work as follows:
A hacker, using a leaked password database or employing dictionary or brute-force attacks, obtains a user’s password.
If the leaked password is associated with the leakage of other data, which is often the case, the problem becomes more serious. The hacker then impersonates the person when calling the customer service line of the mobile operator, requesting a duplicate SIM card (sometimes the call center is not enough, and a visit to a physical store is required).
The user’s SIM card expires within a few minutes, and the hacker takes over their phone number.
The hacker logs into the user’s bank account using the stolen password, and the second factor is sent to the user’s number, which the hacker now controls due to the SIM swap attack.
The victim loses their savings because the hacker can authorize transfers and cannot call the bank from their own phone (their SIM card has expired, and the phone can only make emergency calls).
Regarding SIM Swap, we recommend reading the article from bleepingcomputer.
Figure 1 – SIM Swap Attack, source: DHS CSRB
Which factors are the most secure?
The answer to this question is not straightforward, as it depends on the specific needs of each organization. However, it’s possible to identify which factors are less secure. Some factors, such as passwords, TOTP, and SMS codes, are vulnerable to phishing attacks. To put it simply, if a user enters a fake website that resembles their bank, logs in, and provides the second factor obtained from an authentication app or SMS, the hacker gets everything they need to take over the account.
For the average internet user, the best form of the second factor is a U2F key, which protects against phishing attacks. If a particular application doesn’t support U2F (for example, most banks except ING – kudos to them – as of August 2023 in Poland don’t support this form of the second factor), using authentication apps like Google Authenticator is a good option. Such apps use modern, secure protocols and provide a good level of security for users. A less secure form of 2FA (2 Factor Authentication) is SMS/Phone Call. This is because the protocols used in telephony are old and susceptible to certain attacks.
Best practices for the second factor are described in our article about internet security.
Session Hijacking Problem
The last aspect of authentication worth discussing is session hijacking. While a significant portion of attacks, such as password attacks (brute force, phishing) or attacks on the second factor like SMS (SIM swap), focuses on gaining authentication capabilities on the attacker’s side, there are attacks that exploit the mechanism of cookies or tokens. Most web applications use session mechanisms, meaning that after a user logs in, they receive a token (stored in the browser’s memory). With each subsequent communication sent to the server, the received token is attached. This is done because network protocols, including the HTTP protocol used in web applications, are designed as stateless. This means that each client request to the server is treated as an independent, standalone interaction. Due to this, the server naturally doesn’t retain any knowledge of previous requests or the client’s context, so it needs tokens or cookies to differentiate users.
Figure 2 – Session Operation, source: thesslstore.com
If an attacker is able to obtain session data from the browser, for instance through a man-in-the-middle attack, malware installation, executed macros, or even by connecting a compromised device to a physical computer, they bypass the authentication process. In such cases, two-factor authentication is ineffective. However, this doesn’t mean it should be abandoned. Session takeover attacks require much greater technical skills and are far less common than the fraud methods described earlier.
Figure 3 – Session Hijacking Attack, source: cyberhoot.com
To draw an analogy, imagine you’ve bought a ticket to a festival. When you arrive at the registration point, you might be asked to present an ID and proof of payment for the ticket. This takes you through the authentication process. After registering your presence, the attendant hands you a wristband that you wear during the concerts. From that point on, any security personnel can simply glance at your wristband and know that you’ve been authenticated and have access to the different stages at the festival. However, if someone steals your wristband, they now have the same access to the festival as you do.
Cookies work the same way. They’re simply digital versions of wristbands.
Summary
We hope we’ve managed to familiarize you with concepts related to authentication and how the second factor should be used. Let’s remember that U2F keys are the most secure way to implement two-factor authentication. If you want to take better care of your security, we encourage you to get in touch with experts or continue reading on our blog. We particularly recommend our series on security advice. See you in a week!
Sources:
