Learn about how attackers use leaks or flaws in the authentication or session management functions—exposed accounts, passwords, session IDs—to temporarily or permanently impersonate users.
- [Narrator] The second item in the OWASP Top 10 is broken authentication. This actually covers two distinct but related categories of attacks, those having to do with authentication, and those having to do with session management. I'm going to tell you about the basic concepts behind authentication and session management, as well as a few of the common attacks that can result in user accounts being taken over by hackers. Fundamentally, authentication has to do with what is yours and proving that you are indeed you so that you can access your stuff.
The most common and familiar form of authentication is a username and password. For example, in order to authenticate to the LinkedIn application, you type in your username and password. This tells LinkedIn that you are the person who owns the account you are accessing, and by entering the correct username and password you can access your account and do whatever you want with it. The term session is used to describe the interaction between a user and their account when the user is actively using the account.
For example, you start a session on LinkedIn when you login to your account, and that session is active until you log off or until the application automatically logs you off. Of course, I've just described authentication and session management in a way that assumes that an account is being properly accessed by its rightful owner, and that the only person using an account during a session is the person who actually created and owns that account.
Attacking authentication mechanisms and session management is very attractive to attackers because when those attacks work, they can basically do any and everything that a legitimate user is able to do. Because of social engineering tactics, automated attacks, and incorrect implementations of application logic, each of which I'll go into in a bit more detail in just a moment, these attacks can be relatively easy for a hacker to implement and also quite damaging.
One of the easiest and simplest ways to hack someone's online account is to convince them to give you their username and password. This can be done online by sending someone an urgent email that asks them to logon to their account immediately in order to fix something bad which has happened or prevent something bad from happening. For example, an email might say something like, "Your account has been compromised, "and in order to restore it you need to logon "right now by providing your username and password here, "and we'll get it fixed for you right away." It's ironic, right, that a hacker would pretend to be securing someone's account when actually they're stealing it.
These types of social engineering attacks can be conducted either online via email or on the phone. The thing is that it works. One reason is because these types of attacks are often characterized by a sense of urgency. If you receive a message or a phone call that you suspect might be a social engineering attack, do not give them your username and password. A legitimate organization will typically not ask for your username and password.
If you're concerned, the best way to proceed is to contact that organization by visiting their physical location or going to their actual website and calling the customer service number directly. Of course, there are more ways for a hacker to compromise someone's username and password beyond just asking for it in a very clever way. Because modern computing provides a lot of processing power at a very cheap price, it's relatively easy for a hacker to simply run a computer program and guess a user's password.
Credential stuffing is a technique that refers to when a hacker uses the usernames and passwords which were revealed during a data breach and tries them against different accounts. Consider a data breach in which all of the accounts managed by company A were revealed, all customer usernames and passwords exposed. A hacker would then run a piece of software that would systematically run through all of these exposed usernames and passwords against website logins for company B, company C, company D, etc.
Unfortunately, this works because many people use the same username and passwords for different websites, applications, and accounts. If a hacker does not have access to a database of already compromised usernames and passwords, they can use resources such as the top 10,000 worst passwords and try them for whichever usernames they like. Alternatively, they can use brute force programs to systematically try out a list of automatically generated passwords that basically run through every combination of characters until they find one that is a match.
One way to prevent that's kinds of attacks is to limit the number of attempts that a user can provide an incorrect password before some kind of stalling tactic is used. For example, if I try to logon to a particular account three times and I don't use the correct password any of those times, a more secure website might lock me out from trying for one minute, or five, or 10. They might either require that I call a customer service number in order to access my account because they suspect that a hacker and not a legitimate user might be trying to access the account by guessing the password.
Another prevention technique is to use multifactor authentication, which involves the user entering a one-time code in addition to the password when they're logging in. They can get the code from either a hard token or from a software token. The last scenario that I'll discuss here regarding broken authentication, is improperly implemented application logic. As an example, I'll talk about a very common application flow, one that I'm confident that you've been through yourself at one time or another.
It's the forget my password workflow. Of course, these are put in place with the intention that a legitimate user has actually forgotten their password. However, it's fairly easy to make a mistake when implementing this type of application feature, and certain types of mistakes will allow hackers to bypass the intended security controls. Let's walk through the typical steps involved in a forgot my password flow. The first step is to get verification data from the user before the user has forgotten their password and needs to go through the work flow.
This might involve something like having the user choose a few questions and submit answers to those questions that presumably only they know the answer to. The second step happens when the user enters the forget my password flow. At this point, the application prompts the user by asking for the correct answers to the questions which were selected in step one. The third step should be to lock the user out of their account so that the previous password no longer works.
At this time a new code spacer block sent to the user. Ideally, the code is sent out of band, perhaps to a second email on account or via SMS. The reason a code is sent through a different channel is in case the primary channel has already been compromised by a hacker. The final step in the workflow is for the user to submit the code they just received to the application, and for the application to then allow the user to reset his or her password.
Sounds straightforward enough, right? After all, we've all been through this flow at least once or twice ourselves. But because this particular application business logic deals with access, a mistake in how it is implemented can accidentally give a new password and associated account access to a malicious attacker. The first thing to look out for is in step two when the questions are being verified, that the answers are not provided in a drop down and that the username is not sent out during this step.
It's too easy for an attacker to guess when the options are provided in a drop down format. And giving away the username when the attacker might not have had it in the first place just makes it that much easier for them to gain access to an account that does not belong to them. In step three, it's really important that the application locks out the user. This helps to ensure that if the hacker obtained a working password at some point, that it will no longer work.
Finally, it's critical that step four does not happen unless at least step one and step two have already occurred, and the correct information is verified. It's a simple mistake to allow an application to get to step four without ensuring that step one and step two happened first. This is something that needs to be tested once the application has been developed to ensure that the functionality and business logic occurs in the way it was meant to be.