On this episode, James talks about the risks and recommendations for using security questions with your applications. Tackling the challenge to integrate security into the development process? Looking for insights, answers and practical solutions to avoid getting overwhelmed? Hey everyone, welcome to the DevelopSec podcast. I'm James Jardine, your host. And I got a question for you to start this episode off. How do you feel about security questions or also known as secret questions within our applications? Those things that ask us, hey what's your mother's maiden name or what's the color of your first car? Simple things that oftentimes we can find, funny enough, sitting out on social media where we post so much information or share so much information. And I saw just the other day, well actually a little while ago now, somebody had posted on LinkedIn, they were talking about security questions and giving out some tips, which was great. I mean, it was a great little info session talking about some different tips you can use for your security questions. And I thought, you know what, this would be kind of a cool thing to talk about because a lot of people I see that I work with, they struggle with the concept of security questions and understanding how they should implement them in really a secure way because what we call them security questions, rarely are they really secure, right? Because like I said, a lot of these are really basic answers. There are stuff that we can find out there. What elementary school did you go to? Way back before we had so much internet, maybe that would have been much more difficult to identify for just the random person out there, but now you can just start googling that information and start finding that type of information on people. So answering them properly makes it really difficult, But we often use security questions as a means to identify a user if for some reason they have maybe forgotten their password. And or especially if you're calling like tech support, Maybe I'm not having the ability to have an email link sent to me, although we could still do that with tech support. But they ask us something to verify that we are who we say we are, because for some reason, either they don't want to accept our password, right, because we don't want to tell them our password while we're talking to customer service, or we need some other way because we don't know it and they want to validate who we are before we reset our password. And so we have this idea of, hey, this is something you know, and nobody else should know, And unfortunately, that's not really that true anymore. So we have these security questions out there and we have a lot of places that implement them, but we gotta figure out how we can implement securely and think about some of the risks that are around them. And before I start going into that, I had kind of an interesting story talking about security questions that happened to me years ago, right before I got married. My wife's friends, before they were having some little bridal shower for her, they decided they wanted to ask me some questions. They were gonna have me answer them, they were gonna video me answering them, and then during the bridal shower, they were gonna show them asking the question and then give my soon-to-be wife the opportunity to see if she could guess what answer I would give for those questions. And then after she answered, they would play my clip of me answering it. You know, I guess kind of interesting, I wasn't there, obviously it was a bridal shower, so I just got to do the filming part. But what was interesting is 1 of the questions they asked me was, what's your mother's maiden name? And I liked it. I said, I'm not answering that. And they kind of got a little upset with me, but I'm like, look, I said, that is the most commonly used security question out there. What's your mother's maiden name? It's everywhere. I'm not gonna tell you that. And so after going back and forth and arguing about it for a little bit, they finally were like, fine, let's move on. You're not gonna answer it, that's okay. Well, I talked to my wife when she gets back from her bridal shower, which was I think a week later or so. And there she is. She's like, yeah, they had this whole question, what's your mother's maiden name? And so they asked me and I said, he won't tell you that. And sure enough, that was what I said. I wouldn't tell you. I'm not going to answer that question. So it's kind of funny when we think about these security questions, you don't know when they might come up. And, you know, I'm constantly kind of thinking about that type of stuff. So I'm like, I'm not going to answer that. It's very common. So no, I'm not going to share that. And, you know, I'm kind of glad to see that my, my wife understood that about me that he's not going to answer that. That's, that's kind of silly. So security questions are out there. We have them all over the place. So if we understand what some of those risks are, then we can start thinking about how we can better implement them if we need to implement them So that maybe we can hopefully keep them more secure that somebody can't just go Google some answers or guess the answers And then be able to gain access to our account. So there's a couple different risks that I was going to talk about when we talk about these security questions. And you know, 1 of those is really weak answers. And that's really more about kind of the weak question. You know, if you have something that has very limited answer sets, then that makes it very difficult for us to have vastly different answers. So if I say, what was the color of your car? There's really not a lot of different colors for cars. Although we're starting to see more colors now, drive around, you see some crazy colors now, but I mean really, you know, red, blue, white, black, those are kind of your more common colors and then maybe you'll get a few outliers, but there's not a lot of guesswork going there. So if I'm asking a question like that and we answer it honestly, then sometimes it's not that difficult to guess that or brute-force it, especially if the secret question or security question feature doesn't have some sort of brute force protection and lets somebody just guess all day on supplying that answer. So we wanna make sure that we're trying to find something that's gonna have, you know, really more of a wide open answer. It's not confined, you know, not what's your favorite color because most people are gonna pick red, blue, green, you know, those are kind of more of the common ones. And you'll get people that'll pick something else like magenta or fuchsia, if you can even spell fuchsia, right, that is out there, but for the most part, most people are just kinda going to pick the primary colors. So trying to get something that might be a little bit more difficult to answer, something that hopefully is not blasted all over social media or anything like that. You know, what was a nickname when you were growing up as a kid? It's oftentimes not too hard to find now because people will post that on social media. The other thing we need to think about is weak storage. So how are we storing those answers for our secret questions in our database? Now we think, oh well, what's the matter? I mean, you know, is somebody going to pop our database? Well, we see people pop databases all the time. We see credential leaks all the time. As a matter of fact, a couple years ago, there was a report out there of 1 of the Yahoo breaches, where they actually gained access to your security questions and answers. So they can be found. It's not as common as we see with your normal username and password information being stolen. Maybe they just don't report that, I don't know. But we don't see it nearly as often, that information being compromised, but it can happen. So we want to make sure that If we're storing these values, I always recommend storing them with the same strength that you're storing your password. So if you're using a bcrypt to store your passwords or you're using pbkdf2 or some other really strong hashing algorithm to store your passwords, store your security question answers the same way. So that way in the event somebody gets access to the database, they can actually not, hopefully, decode those and be able to gain access. So make sure that you're doing it very strongly, just like we would that password, because remember that the goal of a lot of times, the security question is, to gain access back into your account when you have forgotten your password. So sometimes it has that same strength as a password. We want to make sure we protect that. And very rarely would we actually need to decode that value. Because just like a password, all I'm doing is verifying that what you provided me is right. And to be able to compare that, I just need a hash. I don't need to be able to decrypt that secret question answer and compare it to what you gave me to be able to know that they're the same. If I just take that same answer you just provided me, and I run it through the same hashing algorithm, and the hash is the same as what I have stored, then I know it's the same answer, and we're good to go with that. So we want to try to think about how are we storing these values to make sure that they are protected. And in some cases, this might fall under data breach notification laws, depending on your state. So if that data does get breached and it's not properly protected, right, there's requirements for notifying the state, notifying customers or users about that breach if those details are released, if they're not properly protected. So we wanna make sure that we protect those. It also helps because 1 of the other weaknesses that we have out there is when you actually have a person on the other end receiving that answer when they ask the question. How many times have you gone out and called customer support or tech support and they ask you the question and you give them an answer and they're like no do you have another answer and then you try to give something else well was there an address before that you know and they start giving you these hints to try to lead you to the answer because they want to help you. They want to help you reset your password or gain access to whatever it is you're trying to gain access to. They're trying to help you. They want to believe that you are the person that's there. So I've had plenty of times where I've been on calls where they kind of, you know, I'm like, I don't know which Which answer this was then they kind of lead you to like, oh, no, is there a different answer? So if we're storing them hashed then we don't have any capability For anyone to be able to start giving hints as to, oh maybe it was a previous address, maybe it was this. Sure they could give some hints, maybe it was the 1 you used before that, but they really have no idea what the answer is. Instead what they are is provided with an interface and when you call in they ask the question, it has a box for the answer, you type the answer, and then it validates. It's either right or wrong. And there's no, you know, oh, it's close, or it's way off. It's just right or wrong. And you either get access or you don't get access. And you know, maybe you get 1 or 2 tries to answer it, but you know, we want to cut that off. And so that leads us into some of the things that we want to make sure we're protecting our security questions. I've kind of already covered that as I talked about the risk, right? From a storage perspective, make sure that we're storing it using a strong algorithm. And like I said, for tech support, create an interface for them so that way when somebody answers the question, they just type the answer in and then it validates whether it's right or wrong. Now this can be a little bit tricky because sometimes people might use capitals or lowercase and stuff like that within their answer to their security question. Maybe I've got a security question that is the name of a store. You know, what is your favorite place to shop? And you, for some reason, put Best Buy with 2 capital Bs. Well, in that case, you may, and I've seen some places do this, where they'll actually lowercase the entire answer, or they'll remove spaces, or, you know, they'll do something to it So that way they're really not as concerned about the capitalization As they are that you have the right answer Because it in that case It's not treated as strictly as a password, although some places also do the same thing with passwords. But it's trying to make it so that, hey look, if you know that it's Best Buy, then you can put that in there and it's going to work. And if you do it all lowercase, you don't have to worry about, Did I do a capital B? Did I do a capital Y? Now, some I've even seen go far enough that if you put in special characters, they will switch them out or even drop special characters. You don't have to go crazy and far like that. People are gonna usually know if they've done something like that, but people usually don't put that type of special character in their security answer. I'm not replacing ats and exclamations and all these different things in my security answers typically. So that's a little bit less of a concern that somebody's not gonna be able to do that. But you can do things like do it 2 lower and make sure that it's going to match. Now, if you're answering correctly and you say, hey, my answer is Best Buy, but I'm gonna do a capital B and a capital Y and I'm gonna do an underscore for a space and then I'm gonna do something else here to try to make it more like a password. Well, that makes it a little bit more tricky and that makes it a little bit more difficult when you call in, but not more difficult when you're actually doing just normal, I get to input it myself. And you can read through it and post it in. 1 of the things I recommend is, you know, use a password manager for your security questions. I use 1 for mine that I couldn't tell you what any of my security questions are. I have no idea what the answers are because I don't answer them correctly. Instead, you know, I kind of make up answers to them so that way they have nothing to do with the actual question. And then I store it in the password manager. So that way, if I have to call in or if I have to answer 1 of these questions, I just open up my password manager and I can grab that value and then I can use it. Saves me a lot of headache from wondering, oh, did I use something that would be easy to guess for that. You know, it just makes it a little bit easier. It makes me sleep a little better at night when I do something simple like that. So you can think about doing something where you're using a password manager to make sure you're not picking something that's relevant to the answer or the question that's being asked. Because that can often lead to account compromise just because somebody has been able to figure out what those answers are pretty simply. Another thing I always recommend is, you know, put the security questions behind something. So don't make it that if I forget my password and I go to forgot password, rather than straight up answering the security questions, I typically usually recommend, look, force an email send. So you forgot your password, enter in your username. It's gonna give me the generic because we don't want username harvesting. You know, an email has been sent. You get an email with some sort of, you know, link that you click that's only good for so long. You know, you click the link. And then once you've validated that you now have access to the email account. So step 1 of the hack that would be happening, then prompt the user to be able to answer those security questions versus answering the security questions to then move forward in the next step because now you're putting them out there. I'm trying to manipulate the system in the fact that I want to make it harder to gain access and so in this case you'd have had to already compromise the email account to be able to then gain access to the security questions versus being able to guess all the security questions first and gain that access and then figure out, okay, I've gotten this far. Now, let me go in and try to compromise the email account. If it even goes that far, some systems you can just answer the security questions And then if you get them right, you can reset the password. I don't recommend doing that just because so many times security questions get popped. We saw it years ago during the elections where Sarah Palin's Yahoo account had gotten breached because somebody was able to answer the security questions to gain access into her account. So we want to make sure that we're putting those kind of behind something. I like to think of it kind of like that paywall. I got to do something and show that I have access to something before I'm going to give that answer these security questions prompt. Now obviously we can't do that when we think about we have to call in to tech support or customer service because I don't know how I would do that unless they send me a message or something maybe they could send me an email but even in situations like that Lots of times they can send you a reset link to the email address on record and say, oh, okay, you need access, let me send you this link. They can trigger off that initial link that will then start the process to reset, or at least be able to show that you do have access to that email address, you know, to hopefully help identify that you are the person. And we can also throw in there, you know, sending SMS messages, if we wanted, there's other ways that we can try to help prove who we are, by different devices that we may have or things like that. So those are just some of the things that we can think about doing that when we're talking about doing security questions, trying to help implement them in a way that doesn't open them up to the world, you know, that just any user browsing the internet is not going to be able to just get to the page to answer your security questions, that you're storing them in a way that's going to help protect them in the event that 1, that account gets breached somehow, right? That database gets breached. Or 2, we have somebody in customer support or tech support that may be, you know, hinting around at what it might be because they see that the user's close, you know, and they want them to get there. And I can get that. I mean, I understand it. You know, I can only imagine being on that side of the phone and somebody's answering and you can just see like they are that close, like, you know, they know this and you want them to be able to get it. But obviously You can't say it's this, but you have a pretty good idea this is probably it. But we have to keep in mind that this is how a lot of breaches happen, right? It's through social engineering and using things like calling support to bypass some of these technical controls and then try to answer some of these questions to be able to then take over an account. So we don't want that to be able to happen. We want to make sure that we're protecting users accounts. Some places are not asking the typical questions, you know, some places now require you to set up a pin. So before you can do anything with us over the phone, you have to be able to give us this pin that you set. And usually, they're like 4 or 6 digits. But you have to be able to provide this pin. If you don't have that pin, we're not going to talk. You have to come into a store or something like that to be able to prove who it is. So think about security questions, make sure that you're implementing them in a secure way. If you have questions, send them out to me, james.developsec.com, or hit us up on Twitter at DevelopSec. And just think about it, share your thoughts, and we will catch you the next time on the DevelopSec podcast. We'll try to keep this going a little bit more regularly. So look to hear and see everybody soon. Thanks for listening. You have been listening to the DevelopSec Podcast with James Jardim. To find out more about how we can help you with application security, follow us on Twitter at DevelopSec or check out our website at www.developsec.com.