บทถอดความฉบับเต็มของ Ep. 126: Avoiding Panic and Misunderstandings with Proper Authentication Failure Reporting

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. 00:07:09.660 --> 00:07:49.740 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. 00:07:50.379 --> 00:08:08.459 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. 00:08:09.029 --> 00:09:09.000 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. 00:09:09.879 --> 00:09:43.169 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. 00:09:44.049 --> 00:10:27.230 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. 00:10:27.870 --> 00:10:48.669 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. 00:10:50.360 --> 00:11:05.399 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. 00:11:05.480 --> 00:11:31.450 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. 00:11:32.089 --> 00:12:07.830 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. 00:12:08.570 --> 00:12:59.669 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. 00:13:00.330 --> 00:13:19.129 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? 00:13:19.129 --> 00:13:26.570 Wow, every time I log in or I fail to log in, it doesn't matter which way, it always tells me this. 00:13:26.649 --> 00:14:24.519 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. 00:14:24.669 --> 00:15:24.350 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. 00:15:25.070 --> 00:15:32.669 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. 00:15:33.229 --> 00:15:36.269 We should have that capability to adapt ourselves. 00:15:37.230 --> 00:15:51.519 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. 00:15:51.519 --> 00:15:55.559 We're@developsec.com and we'll talk to you on the next episode. 00:16:00.840 --> 00:16:13.639 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.