Here we are again at the INFOSEC skills learning path. This is the 2021 OWASP top 10. We are on security risk, number 7. We're pretty deep into this thing now. Identification and authentication failures. What's going on with identification and authentication failures? Well, let's check it out. Let's hop on into this thing and let's explore this security risk. To get into this identification and authentication failures, let's talk about authentication for just a second. Authentication is verifying that an individual or entity or website, whatever is who it claims to be. This is typically done by username or ID and either a password or biometrics scan or something like that. Then you can see down there that last one, confirmation of the user's identity. Authentication and session management is critical to protect against these authentication related attacks. When we talk about authenticate yourself, then that's all about saying, I need to verify that you are who you say you are. Keep in mind too, with a lot of applications today, it's not just a human interacting with the application. It can be a machine or another application interacting with the application. Or there can be a variety of API endpoints that you're interacting with. You need to validate or verify who you are to that API endpoint or whatever it is that you're trying to access. The concept of this identification, authentication failures is that sometimes applications allow a variety of different users, or so-called users, maybe attackers, in this case, access into an application. Because of the identification problem, the authentication problem. Because they did not authenticate the user properly before they allowed access. Just I wanted to go over authentication briefly as we get into this entire topic. From a very basic perspective, you can see there on the left, a user wants to gain access to some a web server or application server. Then that application is going to say, I'm going to need to validate you before I let you in. There are a variety of ways that you can validate users. Like I said, a lot of applications use either a username or some an ID along with the password, or maybe some multi-factor token or biometrics scan. There's a variety of ways to do it, but nonetheless, you need to validate, you need to authenticate that person is actually that person or that machine is actually that machine before you let them in. Let's take a quick look at the factors that we've taken a look at. Along the way here you can see that for this particular risk, there were 22 CWEs mapped for this max incident rate, it was not as high as others, 14.84 the average incident, 2.55. Those are the applications that were vulnerable to those one or more of those CWEs that were mapped to this risk. You can see the exploit 7.4, so that's a big number. From an exploit perspective, how easy is it to exploit these authentication identification failures. It's pretty easy. Then you can see the average weighted impact was 6.5. That's also pretty high. That's certainly above half, it's above five. Again, those are out of 10, each of those exploiting impacts. The story that those are telling is it's easy to exploit these problems and they have a pretty significant impact on your organization. That's not a good thing. Then you can see their max coverage and average coverage. These are the applications that were actually tested against those CWEs. Then the total occurrences 132,195 were vulnerable. Again, that's out of just over 500,000 applications that were tested. It's a decent size number. It's saying 28 percent, a little more than 20 percent. Then total CVEs, there's almost 3,900 vulnerabilities associated that are mapped back to those 22 CWEs that were mapped to these identification and authentication failures. Lots of opportunities for attackers to exploit a whole bunch of different vulnerabilities that are tied to this risk. Anyway, so those are the numbers, those are the data factors that the OWASP teams use to figure out, where are we going to place this particular risk. It lands here on number 7. I wanted to talk for a minute about the problem of credential stuffing, because this is one of the problems related to authentication identification failures. Just as a quick discussion, a quick definition, if you will, on what credential stuffing is and why it's a problem. The idea of credential stuffing is that an attacker will steal credentials from a certain place. Then they will take those credentials and they will use them on another place. If you can steal credentials, in this case from Yahoo, in fact, Yahoo years ago that was actually a big target of credentials attack of data leak, that whole thing, then the idea is that human beings, frankly, will reuse the same username and password on multiple sites. Because it's like I just can't be bothered with remembering all of the different usernames and passwords that I have to remember. The concept of credential stuffing is that an attacker, whether they are the ones that steal it or maybe someone else steals it and then the attacker just purchases on the dark web, or maybe they find it online somewhere on some post or whatever, nonetheless they get access to these stolen credentials and then they take those stolen credentials and then they start using them against other sites. Obviously the stolen credentials work on the site that they were stolen from because that's where they got them from. In this case Yahoo, and this little example right here. But again the idea is, let's pick on me for example, if my username is John and my password is password and I use that on Yahoo, and because I'm lazy and I don't want to be bothered with remembering usernames and passwords to a 100 different places. I use John and password again for my Gmail account. Or maybe I use that on my Netflix account also, and also on my Disney Plus streaming and also on my whatever it is, maybe my bank account, I use the same thing. Well then the attacker can take those credentials that were stolen initially from Yahoo and then try them on all these other sites and lo and behold, they're probably going to hit a match on at least one of those. The reason it's called credential stuffing is they'll take those stolen credentials and just stuff them into these other sites that very likely have the same username and password because of the laziness of the user as it were. That's the, that's the idea of credential stuffing. The moral of the story there is don't reuse the same password over and over, or the same username and password combination, and so then you won't be as susceptible to credential stuffing attacks. Here's just a bit more of an idea there. The attacker, they have stolen the credentials from, let's say Gmail or whatever it was and then they send the username credentials until they get a successful login. There are a variety of different attack tools that you can go check them out, or attackers have at their disposal. These are not hard to find at all. That will automate the username and password, fill action on a website. Some of the tools are pretty elementary and it just throws in a username and password right into the username, password fields. Some of them are a little bit more advanced where they'll try their best to mimic real human behavior to say, "Let me open up a web browser or maybe like a Google Chrome browser," and then let me wait for a couple of seconds and then let me type in not really, really fast, but a slower typing to mimic human typing and then just over and over and over stuff in these credentials. Again, you can see there if they have a whole list of different credentials. This list that you see here on the screen, the example would be admin username, admin password or root default or John password, there's moss and password. Or test, test, whatever it is. Then they're going to get a successful log in. They're probably going to get a bunch of successful logins, it's the truth. Then they can keep track of that, and again these tools help them with all these things and say maybe you've got 100,000 or maybe a million different stolen credential, username, password, combination pairs, then you've stuffed all those into bank.com or maybe Netflix or maybe Hulu, you pick it, right? Then. It will say, hey, out of those million you had 300,000 hits or maybe you had 100,000 hits or something like that. Well, if you're the attacker, you're like, man, I've got 100,000, I'll pick on Netflix again. I've got 100,000 Netflix accounts now that I know work. I can turn around and sell those maybe again on the dark web or on whatever and make some money off the thing. There's a whole bunch of different ways that attackers would use this credential stuffing attack, but that's the nature of it. That's a problem again when it comes to authentication and identification failures for web applications today. Here's just a list, I frankly went to Google, which then led me to GitHub that gave me this. You can see there, these are extremely easy to find. If you look on the right hand side, then some of these are pretty dated. Some of them are like four or five years old, but some of them are five months ago. There's one that's three days ago. These are default credentials for different manufacturer items out there. There's honeypot captures, there's leaked databases. You can see right there and this is just that initial top screenshot of what is thousands and thousands of entries. Each of these are just huge text-based files that have a ton of usernames and passwords in them. The point here is that it's not that hard to go find the credentials, if you're out there looking for these things, then you can find them. That's what attackers will do, is they'll go find these credentials and then start to stuff them into a variety of different applications and see what hits. Here's one credential stuffing compromises more than 1.1 million online accounts. This was in January of 2022. Fairly recent after the 2021 OWASP top 10 list was released. You can see the millions of passwords is in the wild tied to email addresses provides an easy attack vector. This happens all the time, is the bottom line here. Again, the problem is that people reuse their same username and password. Then this is what the attackers do with it to do all bad stuff. Credential stuffing is a problem out there. There's another problem of continued use of passwords. This is one again, this just frankly goes back to the laziness or the human behavior. I know I keep saying laziness. Maybe it's not always laziness, maybe it is. But let's say it's time to reset your password, and you get this system-generated email and it's like, hey, it's been three months or it's been a month or whatever your organization is. They say you must use at least eight characters , upper, lowercase, numbers, special character and it can't be any of your previous five passwords. There's a lot of password capabilities or configurations that administrators can set up to say, hey, here's the credential or the password complexity requirements. You can't reuse like X number of passwords, so let's say that those were the complexity requirements in the previous passwords, you can't use. If your current password is P@ssword1!, then you got to put that exclamation point, although it does have the little at sign there for the A, so that's a good special character. Not really, that's not a good special character here. These are horrible passwords in case you didn't know. Then let's just say because you don't remember whatever you don't want to have to keep up with it, then the next password is P@ssword2. You can see down there the question. Guess what the next password is going to be? If you're an attacker and you gain access to this username and password. Then maybe the user finds out that, hey, my password has been compromised, it's time to change my password, reset it or whatever. If the nature of you as a human is to say, well, let me just go down and the next one is going to be P@ssword3!. Well then as an attacker, you can anticipate that and then you don't even have to steal it at that point. You can just start to use it because you know what's going to work. Obviously, you would test it to make sure it works. But that's another problem when we talk about the continued use of passwords. I will make a quick statement here and I've mentioned this in a previous video about password managers. There's a bunch of them out there, a bunch of good ones out there that you can check out. I've heard some people say that they use password managers, which I would recommend. It helps you keep track of all your passwords and you can make them really complex and all that stuff. It's better than just trying to remember them on your own. But I've also heard people say, I let the password manager keep up with my passwords. However, I add a few extra character. If a password manager were to autofill my password for whatever login I'm trying to do, then I'll let it autofill the username and password. But then I actually type in maybe a couple extra characters or a couple extra numbers or whatever it is, at the end of that password that's saved in the password manager. The actual password for the application is whatever the password manager auto fills, plus those few extra characters that you type in at the end. All you have to remember is those few extra characters and not the whole big crazy complex one. The password manager, if that were ever to be compromised and the attacker used that saved password that's in the password manager. They still wouldn't be able to get in because they don't know those last few characters that you type in at the end to gain access to the application. That's a little trick that you could maybe try to use if you don't just want to use the password manager directly. Anyway, so that's a little word. Another thing when it comes to authentication and identification failures is session timeouts. Let's say that there's this shared public computer at a library or something like that. A user authenticates properly, they use the username and password and all the different stuff, maybe even multi-factor authentication and we'll get into that here in a second. They do the biometrics scan, possibly, summing all this stuff. They've authenticated properly. Then the application server says, okay, I'm going to apply or create a session ID or this application session, and it's going to be established for the duration of however long you're on the computer, however long you're accessing this application. Then let's say though that the application was built in such a way that it has just a set established session time. Let's say it's sets it for 30 minutes or maybe one hour or whatever it is. Regardless of whether the user's steps away or closes the browser Window or whatever it is, that session ID is still active if the application has been created that way. What this does is it opens up the possibility that another person could step into that shared computer, maybe it's in a hotel lobby, whatever it is, and then they could go access that same application, and behold, you are still logged in because your application session was established for a set period of time, and not necessarily for the duration of the session that was being used by that user. All that to say, it's important to establish session timeouts on the application side. To say that when a user authenticates, then you establish the session, but as soon as they log out or they close the browser, then you need to kill that session, so that the next person can't just walk in and take over and act like that authenticated user. I know I've mentioned this a second ago. Another point here on multi-factor authentication. It's fairly common today. The chances are you've either heard about this or you've used this many times. But the idea is that a user on the left wants to access their web server, their web application. They say, here's my username and password. Then instead of the web server or the application server immediately giving them access to the application, then that server is going to reach out and talk to an authentication server. This is the Multi-Factor Authentication Server, and then that authentication server is going to send some request or a challenge, if you will, to some external device. Most typically today, it's to your mobile phone. Although it could be to an email address. You can have a digital token in the form of a USB key that you may plug in to a computer. But most typically I know for me personally, I've got my phone and it sends me a text, and then it says, hey, here's the number or whatever that you have to put in. That authentication server will reach out with that authentication code, and then as soon as you via that external device, in this case a phone, punch in the number, then that number goes back to the authentication server that says, hey, web server, application server, this user has punched in the correct number, and so they have now authenticated via this multi-factor. It's not just username and password, now it's authentication token or an authentication code. Then that server reaches back up to the web server and then the web server says, okay, access granted, now you're in. The good thing about multi-factor authentication, especially with respect to the issues that we've talked about a second ago, whether it's credential stuffing or session timeout, and especially credential stuffing, I should say, is that if you as an attacker, have a whole list of usernames and passwords that you have either stolen or bought from other stolen list or whatever, and then you try to stuff those into an application server, and that application server utilizes multi-factor authentication, then you're going to need to figure out a way to get around the multi-factor as well. You can't just simply credential stuff and get granted access to that application. Multi-factor authentication can help with credential stuffing. I'm not going to say that it completely erases it, but it can certainly help with that. Let's look at things that you can check out or ask yourself when it comes to vulnerability to this identification, authentication failure problem. These are several things that you can ask yourself or look at to say, hey, do I do need these things? Do you permit automated attacks like credential stuffing? If you do, then that could be a problem. There's different things that you can do. You can certainly deploy a botnet type of security service, if you will, that will check for these bots. The reason for botnet is most of the time attackers are not sitting there typing in credentials themselves and hitting go, they're feeding these into a significant number of bots that are part of a botnet that either they own or maybe they rent them out. It's like botnet as a service thing. They'll use the botnet to stuff all the credentials. On the application side, if you're saying, "Hey, I need to check and see how protected am I against automated attacks like botnet type attacks?' You need some capability, whether it's of a botnet type service or a botnet defense type service, or just the application itself is built in such a way that maybe there's rate-limiting on how many usernames or passwords can be entered in a certain period of time, that thing. There needs to be something like that. If you permit brute force or other automated attack, this again it's what I was just saying. If you permit default weak or well-known passwords. This is where you as an administrator can say, hey, I'm going to explicitly deny my users that create usernames and passwords on my application. I'm going to say you are not allowed to use that as a password. If they're trying to use password one or password exclamation point, then you can say no, that's not an acceptable password. There are list and in fact, here's what you could do. You could go out to those same list like on GitHub or whatever and say, let me download the top 10,000 worst passwords out there. The passwords that are most easily guessed or the ones that attackers use the most when it comes to credential stuffing or that thing. Then I can take that list and feed it into my application and say that none of those passwords are allowed on this application. You can be proactive in that way. If you use weak or ineffective credential recovery, such as knowledge-base answers. And we talked about that in another video where if an attacker could go and find out your mother's maiden name or the street that you grew up on or your first dogs or pet's name or whatever, then those are not effective credential recovery processes and those can be manipulated as well. Make sure you use proper forgot password process. Basically don't use knowledge-based answers, which can be manipulated. If you use plain text or weakly hashed passwords, this gets into some of that credential stuff or the cryptography stuff I should say that we talked about some of the week, hashes and those things. Certainly don't use plain text passwords. If you have a missing or ineffective multi-factor authentication and we talked about multi-factor a second ago and how that's important. If you expose session IDs in the URL, so you don't want to do that. We talked about session ID. Don't let that be present in the actual URL because it's easy whether someone is shoulder-surfing as they walk buy or whatever they could rewrite URLs. Or if you're doing URL rewriting, that can be a problem in terms of session ID exposure. Then don't rotate session IDs after the successful login. I'm sorry, if you don't rotate session IDs or if you don't properly invalidate session IDs, then that's a problem. Maybe set a different way you need to rotate session IDs after a successful login and you need to properly invalidate session IDs after logout or browser close that thing. The idea there is again, you need to protect that session ID so that someone else can't come in and just steal it and use it on your behalf so that would be a problem. Protect yourself. A lot of this is going to be the opposite of what we just said. Are you vulnerable, do the opposite, and don't be vulnerable. But here, implement multi-factor authentication. I know we've talked about that, so I won't belabor that point. Don't ship your code or deploy your application with any default credentials, certainly for administrative users. This gets back to the factory or just the default credential list that you can download a million of those lists online today and if you're shipping or you're deploying code that has default credentials in it, then that's not good because that's just a very easy attack exploit for an attacker to take advantage of that. You should implement weak password checks like I talked about before, test new or change passwords against the list, this top 10,000. Pick whatever number you want, the top 10,000, top 100,000 whatever worst passwords and just don't let those be used in your application. You should align your password complexity, the length and the rotation and all that with NIST guidelines. Rather than saying, "Hey, this is exactly what it should be, this many characters," it is good to just say, let me point you to the NIST guidelines, the National Institute for Standards and Technology, and just say whatever their current guidance is, is a good guideline to go with. As those get updated, just keep pointing there thing. Then you can see that last one, ensure registration, credential recovery, API pathways, all that are hardened against account enumeration attacks by using the same messages for all outcomes. Basically what that is saying is if you're going to give some sort of an error message or a password, invalid password or that kind of thing, then regardless of the outcome, you should say, Hey, let me just have a generic, an error has occurred or login unsuccessful or that kind of a thing. Then that way you're not giving away some of the secrets as to exactly what happened to the attacker. That's a good thing to do, as well, just keep those messages the same for all outcomes. A few other things here, limit or increasingly delay failed login attempts. I've seen on an iPhone, for example, if you punch in the wrong pass code, then they're like, Oops, sorry, try it again, then you punch it in again. If you punch it in enough times wrong, then it says, All right, we're going to take a couple of minute break here and let you think about your password or your pass code. Maybe it's like, Hey, you can try again in five minutes. Then if you punch it in wrong again, then it's like, Okay, we're getting suspicious here, we're going to make you wait 30 minutes. You punch it in again wrong and it's like an hour or so, it starts to step up. That's that delayed failed login attempts. Again, if you use that same type of an idea on your application login, if you're an attacker and you're just launching this botnet at the application, and the application says, Hey, you failed the login once, okay, fine, I'll let you try again. But after maybe it's two or three unsuccessful logins, then I'm not going to let you try again for a few minutes. Then, now what's going to happen is the botnet is just going to just keep crushing that login page with the username and passwords. But your application is basically just denying every single one of those until the timer resets or whatever. That can also alert you. It says right there log all your failures, alert your administrators all that, that can alert you to an attack, that it's like, Hey, I've locked out this account for five minutes or for 30 minutes or whatever, and it is still just getting absolutely slammed with requests. Guess what? We're under attack right now, we're under a credential stuffing attack. Some botnet is just crushing our login page so let's take action on that. That's something you can do. You can see there your server-side secure built-in session manager, it generates a new random session ID with high entropy. That's the, a lot of the change or some of the cryptography that basically makes it hard to guess. It's bottom line there. High-entropy after login. Again, this is where a user logs into an application, a session ID is created as part of that login. But then upon successful login, then we're going to generate a new random session ID that will be used for the duration of that session, so that if that initial ID, session ID would have been stolen, then it's not going to be any good because that initial one gets replaced immediately after the successful login. Then you can see there, don't put the session ID itself in the URL. Make sure it's stored securely, needs to be invalidated after logout. We've talked about that a little bit already. Those are some things you can do just around that session ID, the session management, which again is a critical part of this identification, this authentication failure problem for web applications today. Those are several things you can do to protect yourself against this problem. Then we'll look at some resources here. There are a couple of them there or a few of them from OWASP in terms of the Application Security Verification Standard. I know I've mentioned that several times. There's the proactive controls there at the top. There's a couple of cheat sheets down there at the bottom, the authentication cheat sheet, the credential stuffing prevention cheat sheets. Those are some good resources as well to take a look at when it comes to, do I have an authentication in identification problem, am I vulnerable to credential stuffing. There's stuff out there for multi-factor. There's a session management-type resources that you could take a look at it. All of those would be great resources to consider when you're thinking about, Hey, am I, vulnerable to this particular security risk of identification and authentication failures. Hopefully, this has been a good overview of what's happening out there in the world and some ways that you can protect yourself against it. With that, let me say thanks for hanging in there on this video today, and I look forward to seeing you on the next one.
