On this episode of the devopsec podcast. James talks about the importance of accurate authentication failure messages and when to use them. Tackling the challenge to integrate security into the development process. Looking for insights, answers, and practical solutions to avoid getting overwhelmed. Welcome to the DevelopSec podcast, where our focus is your success in securing and improving development processes. And here is your host, James Jardine. Hey, everyone. Welcome to this episode of the DevelopSEQ podcast. Today I want to talk a little bit about the challenges we face with messaging our users. Whether that's account activity alerts, whether that's the error messages that appear when you're trying to authenticate to the system, you know, the invalid user, invalid password. We have for years given many recommendations on how we should be very vague about the messages that we're providing in some of these situations to help reduce the risk, stop attackers, stop things like username enumeration, brute force, password guessing. But it's actually fairly challenging. And I think there's two different sides to when we talk about the messages that we're giving users. And there's an importance to how we give accurate messaging and when. And to start this discussion off, I'm going to start with a little bit of a story that I saw. And this actually happened maybe a few months ago. I just hadn't gotten around to recording anything about it, but there was a story talking about an application where users were getting phishing emails or text messages telling them to log into their accounts, to check their activity, their authentication activity. And when they did that, they would see entries that were indicating second factor failure or two steps verification failure in their logs. And this isn't available in all applications. I think newer applications are doing better at this, at being able to show you your authentication history so you can go back and track, hey, did somebody log in? That wasn't me. You know, we're all these me logging into this system. So now we've got the better visibility into what's happening with our account and we call this more of the activity alerts. But what happens when we start seeing this information of MFA failed? The first thought I would think going through this, if it's the second factor has failed, is that the password has been breached somehow. Because obviously to get to the second step, you have to be successful in the first step. So if somebody's failing on the authentication of the MFA code or whatever second step that is, my assumption is an initial panic that my password's been compromised. Now, we all know that we should be keeping, you know, separate passwords for every Application, we should be using complex passwords, use a password manager. These are all things that we've been preaching for years. And I think more people have kind of stumbled upon this, They've started using it. We're getting better at it. I think even though the breach password top list of the year always still has password 1 and 1, 2, 3, 4, 5, 6, I think most people are getting a little bit better at this. So you get this message, you log in and you see that MFA factor keeps failing. And so now your assumption is, okay, my password has been breached. There's two options if your password's been breached. Either the provider has had a breach, or there's some sort of info stealer malware on your system. Or maybe you fell for a phishing email and put that information in there. Hopefully you're not reusing the password across multiple systems. So there's one of two things. So you go in, you change your password, make it super complex, 185 characters, all random. Nobody's guessing this in a million years. It's not used on any other system. You change it and then not long after you check in your activity log and you see you're still getting these same MFA failed. And now you start to go a little bit crazy probably you go in and change your password and all of a sudden it's hacked again. Or at least what seems to be hacked again. So now you're thinking, oh my gosh, my system must be hacked. It can't be the end. The fighting system, how would they have gotten that quickly? Usually when the actual provider system is hacked, right, that happens at a given time. It's not happening continuously. Could be, but that's fairly rare. So must be mine. So now you're running antivirus scanners, you're running malware scanners, you're running all these different things to try to figure out, hoping that all your passwords aren't compromised, only to find out hopefully at some point, oh, wait, nope, I don't have anything on my system. It's not me. So it's not you. Maybe it's not the service provider. Well, what's the issue? And so it's actually interesting to find out with a little bit of research that somebody did. It turns out that for the service provider in the web application, in the activity log, they were using the same message for two different activities. And so the two step verification or the MFA failed error message was actually being logged for both when MFA failed. But also, and this is the kicker to it, when the Password failed. So it wasn't that somebody had the password and they were failing on the second factor. It was actually that they were failing on the password. They didn't actually know it, but the system was tracking it as an mfa. So there was a decision made to use the same authentication failure. Probably just assuming that authentication failures, authentication failure, nobody's going to really pay attention to it. Let me just throw this on there. The user will see, oh, yep, authentication didn't work. We're good. Nobody has access to my system. But in this case, because we're using the same value for two different reasons, it could lead to serious concern, and not only from a user standpoint, but also from a business reputation standpoint. If somebody sees this and it thinks that you're the one that was breached as the provider, now you're in defense mode. Now you're trying to prove, no, that wasn't us, it was something else. Right. And in this case, fortunately, there wasn't a breach of any sort of. It just so happened the messaging didn't align with what was actually happening. So we can see that it's important that when you're talking about the activity log and this is where you're logged in, you're authenticated to the system, you're viewing your own information. That authenticate activity log is actually accurate in what's happening. As a user, I'd want to know, was it that I failed my password or did I fail mfa? Because that's going to give me indication of if there's a concern about my password being breached versus something else. Now contrast that with typically what we talk about when we talk about authentication failure messages, when we talk about secure development, training, anything that we're dealing with, PEN tests, always in the history, at least that I've been involved with, it's less about this authenticated activity stream, probably because that is somewhat newer, but more so focused on the actual authentication itself. So when you're at the login screen entering your username and password, that's where we typically talk about the messaging that we're going to provide. And that's where we're usually giving the recommendation of be generic. Don't be specific about what's happening. If the username is wrong, don't say invalid username. If the password, if the username is right and the password is wrong, don't say invalid password. Typically what we would recommend is a generic, you know, statement about authentication failed. I'm not going to tell you why, just that the authentication failed. And even quite honestly, Lockouts, we say, don't tell a user that they're locked out. Keep indicating that the authentication is failing. A user's probably not going to try 100 attempts if they're putting in the same thing and it's failing every time. But we don't want to also give away key indicators of what might be wrong because that does help an attacker try to figure out pertinent information for trying to get into this account. If I tell you it's an invalid user, then they'll stop attempting to brute force those accounts because it's a waste of time. That user doesn't exist. If it's a valid user, but invalid password, well, they know, hey, this is account I can keep trying. Let me see if there's a way to access this account. I'll try different passwords. If we lock the account, then we're telling you, oh, after three attempts or five attempts, the account gets locked. So I can only try so many attempts before I lock the account. So if it's after it's free, then I'll try two attempts and then I'll wait. This information gives enough detail for somebody to work with. It's debatable how effective it actually is. But this is why when you're not authenticated, we're looking to keep the, the information very vague. Just know that the authentication failed. I usually like to have something in there as the generic statement of, you know, authentication failed. Maybe it's a little bit more worried than that. But also then another statement of if you continue to have issues, you know, please contact service desk. But it's always the same exact message. And when I say same exact message, everything's in capitalization, the punctuation, the spacing, everything. It has to be the same message because any deviation in those messages between invalid username, invalid password, those can be picked up on simply with tools. And now you might as well just be broadcasting, that's the invalid username or invalid password. But that's the traditional area we've been at and this is, I think, the challenge. We've always focused on that side of the login functionality and not as much on the activity tracking that we might put in there. Now, maybe it sounds like common sense. Why wouldn't we just put the specific information once you're authenticated that, hey, here's what happened with your activity? Maybe it was a simple oversight. I think it's an easy oversight to make. You're busy putting stuff together. Somebody said, hey, let's put an activity tracker. Maybe there was A constant already created for that, that value. So, hey, if authentication fails in that logic, it just always dropped down to, this is what we're going to put in the log, right? If it's anything past the invalid username, which wouldn't get put in your activity tracker anyway, but anything past that, it's not going to show up in there in that case. So kind of an interesting situation is something I think we don't consider a lot when we're looking at these things. And it's easy to overlook the impact this could have that just this simple breakdown could be used in some way. And this idea that somebody could detect this, right? Maybe I'm a valid user. I found out, hey, you know what? Wow, every time I log in or I fail to log in, it doesn't matter which way, it always tells me this. And then, you know, putting that black hat hat on, you start thinking, wow, I could trick people. If I told people, hey, go check your account, somebody's got your password, you need to change it. And they go in and they see this and they think, wow, maybe my password is compromised. You know, does that lead to easier phishing to grab credentials? Does it cause some sort of panic? Does it cause issues in the media for that organization? Because now people are thinking the organization is breached. So it's an interesting situation, but one I think deserves being called out, because we do talk a lot about vague messaging when we're talking about authentication errors, but we have to be able to break that down into context of is this something an unauthenticated user who shouldn't be able to see this information can. Can see, or is this the authenticated user and they should have a little bit more detail into what they're seeing. So, interesting situation. I thought I would share that with everybody. Let me know if there's other areas that you see, similar things that don't seem very obvious, but when you actually give a little bit of thought, it's like, wow, just that small wording makes a difference. And, oh, here's the context around this, that makes me see how this could be different than that other spot. And I think when we think about principles of vulnerabilities and how that all fits together. And as the years have gone by, we've started talking more about context, thinking about how that all fits together and being able to adapt to those situations, to be able to realize that, oh, in this situation I can do this, and this one I can't. I think those are critical things. As we talk about secure development and building our applications that we have to be able to do that. We wouldn't just reach out to security teams to figure out. We should have that capability to adapt ourselves. So thanks for listening. Hope you enjoyed this episode. I'll have a link to the actual article that talks about this in the show notes, so feel free to go check it out. It is kind of an interesting thing. And you know, again, share your feedback. Reach out. We're@developsec.com and we'll talk to you on the next episode. You have been listening to the DevelopSec podcast with James Jardine. To find out more about how we can help you with application security, follow us on Twitter @ developsec or check out our website at.