24: How to Keep My Mobile App Secure

Security is a never ending game of cat and mouse, and it is important to do the fundamentals correctly to reduce your chances of a breach. Tim chats about all things related to making sure your mobile app system is secure.

In this episode, you will learn:

• How encryption works and how it keeps your user's data safe
• Why you need to use a unique password on every website you use
• When you should sanitize and filter user content (hint: always)
• What to do when you've been hacked

This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.

Recorded October 24, 2019 | Edited by Jordan Daoust

Episode Transcript:

Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholt. Let's get nerdy.

Today on the show, we are talking about a hot topic in the world of technology these days, security. And most importantly, the question everyone's asking is, Can my app be hacked? And the short answer is, yes, your app can be hacked, and it has a pretty good chance of actually being hacked. Security is a never ending cat and mouse game, where you are constantly trying to outwit somebody who wants to steal your data. And because of how fast technology moves, this gets easier and easier for the hacker every day in some ways and more difficult than others. So this is not like a, Well, my app is secure, and you check a box and you're done. This is something that you're going to constantly need to worry about when you own a mobile app. So we are going to talk about some ways to make your app more secure and potentially less interesting to a hacker.

The first thing we'll talk about here is encryption. So, at a high level, just to explain encryption, I like to bring it back to a movie that I watched a million times growing up. And we watched it every day in school, around the Christmas season, it's A Christmas Story. So this is, if you remember Ralphie, he is listening to the Little Orphan Annie radio show, and he saves up and gets this decoder pin. And he's all upset because he doesn't get these secret messages. And he finally gets the decoder pin and they say set your pin to whatever and then they're reading off numbers and he's transcribing as quickly as he can and it ends up being, "Don't forget to drink your Ovaltine," which is a super secret message. But at the end of the day, that's what encryption actually is, is taking a message that you want to send to somebody else and obscuring it, so that a third party can't listen to it and intercept that message. At the end of the day, that's all that encryption is.

Now, obviously, it gets a lot more complicated than that. There's a lot of nuance that goes into encryption. But why don't we just quickly talk about what do you encrypt? Basically, everything, anything, anything that you can encrypt. Data can live in one of two states, right? It can either be at rest on your device, where it just lives on your device in a nice little warm cocoon. Or if you want to get that information onto your server, then it needs to be in transit. So it can either be at rest or in transit. And when it's at rest, you can do things like encrypt the entire system or encrypt the database. It's not as easy to hack into encrypted databases. But when data is at transit, that's when things get a little more risky.

So one thing that we want to talk about as well is how do you actually encrypt things. And there's two types of encryption that we're talking about here, kind of lumping it into one to make this a lot more confusing. So we'll try to make it not as confusing for you. The first way that you can encrypt something is to do what's called a one way hash. So when we talk about a one way hash, what we're talking about is basically a bunch of gibberish that represents an actual piece of data. So what you do with a one way hash is it's basically a function that you can put any kind of string or a piece of data into, it runs a bunch of code, and then spits out a bunch of gibberish. And what this is good for is specifically passwords. So let's say that I have a password that's chicagobulls. It's just chicagobulls. All one word, all lowercase. If I give this hash that phrase, chicagobulls, it'll spit back out a bunch of gibberish. Now, if I give it capital C and capital B Chicago Bulls, and you put it into that same hash, it'll come out with something completely different. It does not look anything like what the original chicagobulls password looked like. So what's great about this is you don't need to actually store in plain text the word chicagobulls. You can store this hash. And then the next time that you want to sign into your app, the user can provide the password. And if that matches what we had as the original hash, then you're good to go. That's at a nutshell. That's basically how passwords get encrypted into databases. At the end of the day, me as an app owner, I don't care what your password is. I just want it to be secure. So I don't need to ever know that your password is chicagobulls, where it should be minnesotatimberwolves. No, it doesn't matter. What matters is that whatever you put in matches what you put in later through that one way hash.

Now, that works great for data that I don't want to actually know. But let's say that there is data that I do actually want to know, like the email address. I can't really, if I want to send an email to you, like if you forgot your password, you can't. The thing about a one way hash is as advertised, you can't go the other way with it and decrypt it. So you need to do two way encryption, that's when data is, like we said, in transit. That's where if you've ever visited a website, like your bank, where it has the little green lock in the corner, and it says HTTPS, that is a secure connection. What happens is you have your data, and then on my end, I give it a special key and password. And then I send that over to the server. And the server already knows that password so it can use that password to decrypt that data, just like Ralphie did with his Little Orphan Annie pin. He can decode that message on his end and get access to the information.

So encryption is complex, right? And that was a lot of technical information all at once. Basically, what you need to know is that data needs to be encrypted while it's going from the actual phone to your servers, and it also needs to be encrypted once it is at rest either on the server or on your device. And if you are doing that, then you're standing a much better chance of having a secure app than if you did not encrypt any of this information at all.

Another thing you can do to keep your app secure is to worry about user generated data. This is one of the biggest areas in which a user can, you know, a bad actor can get into your app through different back doors. So any place in your app that a user can provide data, which is what we're talking about here with user generated data, so think about like signup forms, or your profile page or a profile picture, you need to filter these inputs for poor information or bad information.

So let's take a couple of examples. So email addresses, a very basic thing that you can do to filter is to make sure that they're actually inputting a valid email address. There are standards that exist on the internet that can actually validate that an email address is legit. So for example, we have an app that instead of it's dot com, it's dot beer. So I have Tim@mncraft.beer. You would have never thought that dot beer would be a valid email address, but it actually is. So there's different things you can do to validate that and you can go one step further, if you want to be extra secure, and do things like actually send emails to those email addresses and make sure that they're legit email addresses and not just somebody putting in... I always put in no@thanks.net for example when I don't want to give somebody an email address and it's just kind of junk. Maybe no@thanks.net is a real email address, but I have no idea. If they are I apologize to whoever has that because you've been getting all my junk for years.

Another type of filter that you can do is, for example, profile pictures. This is a perfect place for a hacker to upload something that is not a picture. So if you can check to see on the server side, when you allow a picture to be uploaded to make sure that it is actually a JPEG or a PNG or a GIF or whatever. You don't want them to be uploading like PDFs or like Word files with macros or like JavaScript. You can do things to filter to make sure that that data is actually what it says it is. That wasn't a Denny Green reference, by the way. That's a Minnesota thing for you all.

Another thing that you can do with user generated data is to sanitize the data. So like I said, with uploading JavaScript into a profile picture field, within text fields, bad actors can do things like input database commands and run scripts to try to hack in back doors through your inputs. So you need to worry about... We call that SQL injection. So the best way to prevent against that and another way really overall to beef up your security has to be using industry standard framework. So on the back end, we typically use something like Ruby on Rails. And using these frameworks and using them properly in the way that they were built helps you prevent against a lot of these issues. You still do need to be aware of them, though, because you don't want to, you know, run into an issue where the framework is yelling at you and saying, you know, you've got to be doing this and you say, nuts to that, and you work around it. And it's like, well, you just worked around, you know, a potential, you worked your way into a potential security vulnerability.

Another big way to make sure that your app is secure is around the world of passwords. So I'm sure that everyone listening to this show has a unique password on every single service you use, and you're using something like 1password or LastPass. So we don't even need to go over this. But just for those of you who might still be using the same password in every single place, let me tell you why that is a horrible idea.

So let's say that you use the same email and password on everything that you have, Facebook, your bank account, your work computer. If you use it on a site that is not so friendly, let's say you go to some random ecommerce website for Christmas, and you put in your typical username and your standard email and your standard password. And let's say that that site either willfully or just ignorantly doesn't encrypt your password. They just store it in plain text in their database, and that site gets hacked. Well, now a hacker has access to your email and your password. And then they'll be able to, having that information, they can go around and try that email and password in a bunch of different places like your Wells Fargo account, or Facebook or wherever. And if you're using the same password everywhere, then you're hosed. They completely own your digital life. So this is why you need to have unique passwords everywhere you go and wherever you can, enable two factor authentication. So you've heard what two factor authentication is. But just in case you don't quite understand the concept of it, your password would be considered one factor. So when you go to a website, you type in your email and your password and type sign in. If you have two factor enabled, it's going to check a second source of yours to make sure that you are who you say you are, again, another Denny Green reference. So if you have, basically, you know, you can get a text message sent to your phone, or there's some more secure types of pins that can be sent to different programs that generate random codes. There's all kinds of things. But basically, having two factor enabled on all of your accounts is going to make your stuff more secure.

Now, how does this relate to you as a mobile app owner? Well, again, let's say that you have... Most of the apps that you build that have a back end component to it are going to have some kind of admin dashboard where you can manage users or billing or whatever. First of all, if you're using the same email and password that you use everywhere, then you're just inviting a hacker to get one of those data breaches, like Equifax or wherever, and then plug in your password into your app. And now they have complete control over your system. So this is again, another basic thing you can do as an app owner is use a unique password on all of your systems. And don't just do, you know, your kid's name, their birth year, and then one and then kid's name, birth year, 2. Just please be completely unique and random. And the best way that you can do this, again, like I said before, is using 1password, which is the number one and the word password, or LastPass. These are both apps that help generate unique passwords for every site that you use. So again, biggest pro tip of this episode is get 1password or LastPass. And start using unique passwords on every system that you have an account on.

Another kind of more technical way to make your app more secure, but something that you can talk with your development team about is called IP whitelisting. Every computer that's connected to the internet is connected, is assigned an IP address. Usually this assignment happens at your router. So if you're like at home, any device that's connected to your home network is going to have the same IP address. When you're at a business, if you're at like a more enterprise level, you might have multiple IP addresses. But basically, in a nutshell, every device has an IP address, and what you can do and what your team can do is set it up so that your administrative dashboard and your servers and everything can only allow connections from specific IP addresses. So this is just going to be another step of security so that you don't even have to deal with a bad actor. They can't even get access to it if the only people that are allowed access to it have known and validated IP addresses.

Another big thing that, again, maybe you as the app owner aren't going to be doing but something that you can make sure that you're discussing with your development team revolves around what we call third party data dependencies. I'm very fond of the saying that all software is built on the shoulders of giants. Everything that we build here, like at The Jed Mahonis Group, is layered upon layers upon layers upon layers of code that directly speaks ones and zeros to the actual phone and computer. And a lot of what we do, like I say in a nutshell, is we're assembling Lego pieces to make sure that they fit whatever type of app you're trying to build. So some of these Lego pieces are really important. And they're really crucial to making sure that your app works. For example, there might be a Lego piece that lets you connect to a server and does all the stuff you need to do to make a network connection. Some of these dependencies might not be so important, for example, like the Facebook SDK. One of the best things you can do with adding in a third party dependency is to make sure that it's open source. Just having it be open source is not necessarily like a catch all, we're all fixed and everything's good and dandy, but having it be open source means that developers and people around the world can look through the code and make sure that it's not doing anything fishy. And most of the stuff that you're going to use, most stuff that developers are going to use is going to be open source. Things like Facebook and Google SDKs and other types of things that you might want to do usually for marketing and analytic purposes, are going to be closed source. And if something is closed source, that doesn't mean you can't use it as a third party dependency. But if we're talking about how to make your app secure, that's just another potential back door for, maybe not necessarily a bad actor, but even somebody like Facebook, who knows what Facebook is doing with all the data. If you plug in their SDK, you have no idea what they're actually doing with the data once it leaves your device. They're logging every click, every tap, everything that's happening in your app is being sent up to Facebook, not necessarily like passwords and things. But anything that's going on in your app is all data that you don't know what they're doing with it. So it's just something to keep in mind if we're talking about security of your app, to use third party dependencies sparingly and with good intentions behind it. And if you can avoid closed source dependencies, then you're going to be that much better off.

Along the same lines of third party dependencies is to just use system frameworks. So Apple and Google provide developers with frameworks that they can write apps against. Sometimes what they give you can be a little complex or confusing as a developer, and we sometimes being the lazy people we are, can take shortcuts by plugging in a third party framework that somebody wrote another layer on top of what Apple and Google have done, so that it makes our jobs a little easier. Depending on the purpose of that framework, though, that can lead to issues. For example, we were talking about encryption before, that's the section you guys probably all skipped over because it was really rambley. But there's a thing called SSL. That is the thing that actually encrypts the data and sends it over the Internet to your server. If you use a custom library to encrypt all of that information, that could be pretty bad because you don't know how the encryption is working. It's not been, maybe not been vetted properly. There might be some loopholes or bugs. And more importantly, as things get fixed in the system level, as you update your app, they're just being updated automatically for you. And Apple's doing that hard work for you. You're not having to pay attention to making the SSL libraries updated, or whatnot. So at a high level, make sure your developers are having a good reason to not use system frameworks when they are building out mobile apps.

Another cool thing you can do to keep your app secure is what we call white hat hacking. So if you think about movies, and there's always some nerd sitting in some dark room with a hat, and they're just going to town on their keyboard, clicking away as fast as possible trying to steal all your data. That's what we would call a black hat hacker. Jerks are black hat hackers. The good guys are white hat hackers. So these are people that you would hire that have a particular knack for breaking into systems. You basically hire them and say, Break into my system. And by doing this, they're going to find vulnerabilities and issues and holes in your system that you might not have known about. So then you can take that information, patch up whatever the hole is, and now your app is much more secure. If you're particularly concerned about issues with security, maybe hiring a white hat hacker would be a good way to make sure that your developers are doing everything they can to keep your system secure.

Another great thing that is a necessary thing that you need to do to keep your app secure is to make sure that everything is up to date. So I like to dog on WordPress a lot. WordPress is great. It really is; it powers 30% of the internet. So it's not like it's a terrible tool; like everyone uses it. And the people behind it are really good people but because it powers 30% of the internet, it is constantly being fished out for holes and vulnerabilities. So what hackers will do and I've run into this my entire development career, they'll find ways, like basically they run these scripts that traverse the internet and they find any site that's running a WordPress site, and then they'll run a bunch of scripts to try to hack into it. And older WordPress systems that aren't updated, all these hacks and holes are all known. So they can go in and find back doors into any WordPress system. And then what they'll do is they'll break in, and they'll steal the database and lock it out and basically hold it for ransom against the app owner. And I mean, you know, it's usually if you're, if you at least have a good backup, then it's not that big a deal. You just update the system and reinstall it and you're good to go. But sometimes, you know, people can be real big jerks with how they hack into sites and they can cause some real havoc against a website. So the best way to prevent against this is to keep it up to date. And that means running, not only updating the WordPress core itself, but also the underlying technologies that power WordPress, so we call it the LAMP stack. So it's an acronym so Linux, Apache, PHP, My SQL. I guess that'd be LAPM. I went the wrong way. But you get the point. There's certain technologies underneath it that you need to keep updated as well to make sure that people don't hack into those things.

So how does this relate to your mobile app? Well, like we talked about with third party dependencies, every third party dependency you use, you need to make sure that you're using the latest version of that dependency, not just because of new features, and new additions to it, but because people are constantly patching vulnerabilities in these systems. Especially as you get to things like Ruby on Rails, if you're using like the bigger frameworks like you should, for your back end, you want to make sure that you're constantly patching it so that you're not having a gaping open hole into your servers, and that will leave your data at risk.

Also, making sure that your system, that your apps... You're going to want to make sure that they're updated for iOS, you know, 13 at this point and AndroidX as new versions of the operating systems drop. You want to make sure that you are upgrading as often as possible just to make sure that you are taking advantage of new security features that come with these upgrades.

So everything we've talked about up to this point is what you can do before a hack to make sure that your app is as secure as possible. But like we talked about as well at the beginning is this is a cat and mouse game. And sometimes the cat wins. I don't know who I would be in this situation, if I'm the cat or the mouse, but one way, the other person is going to win at some point. Your system is going to get hacked. What do you do at that point?

Well, first of all, you should be holding hands, basically, with your developer when you are alerted to a hack or a breach of some sort, because you're going to need to be working with them hand in hand to get through this whole process. First thing to do is to take a deep breath and calm down. It is a big deal, but you need to make sure that you're clear headed and not freaking out and doing something to make the situation worse. The first thing you do when you've been hacked is contain the breach. So figure out where they got in, close that hole, make sure that whoever has breached the data is gone, and they don't have any things that are baked in. They sometimes leave little trap doors or little backdoors in the system to get back in at a future point. You want to make sure you scrub through your system and get that breach contained so that the problem isn't continuing to get worse.

Next, you need to figure out the damage that was done. So having good developers, they would have already installed logs to track any access, you know, through the back end. So you'll want to comb through those logs, see what had happened, where they had gone, what data they had gotten, and kind of go from that point, so you have a good understanding of what damage was caused. Sometimes it's they stole data, sometimes, like we talked about with WordPress before, they're just trying to deface the website and they put, you know, something inappropriate on the main page or whatever. But the next step is to really figure out all the damage that was done to the site and get it in a list.

And then once you have that list, the next thing you do is clean up that mess. You've got this list, go down the list and clean it up. Often what works best is, assuming that you have database backups, and you do have database backups, right? You can go in and find the newest one that you have, make sure that that one isn't corrupted. Some particularly big jerk hackers might have breached your system months ago and just kind of laid dormant and hacking stuff and deleting stuff and you might not even know it. So you just have to make sure that you have a good clean database backup that isn't also contaminated, somehow restore that, do whatever you need to do, again, to patch whatever holes came up, make sure that you have updated systems, everything like that, and do everything you can to just clean up the mess that had happened.

Next thing you need to do is get a plan in place to prevent that hack from happening again. Most hacks are going to happen through some vulnerability that is something that you can plan for. Sometimes you just can't plan for things but you need to at least know, where did we fall down? Were we not checking our backups regularly? Were we not doing testing to make sure? Did we have some gaping vulnerabilities? Do we need to hire a white hat hacker? Make sure you have some kind of plan in place so that you can move forward from this more confident that your system is secure.

And finally, once you have done all of those things, and maybe this isn't once you've done all those things, maybe depending on your situation, disclosure needs to happen sooner, but you need to notify your customers. It's the right thing to do. And often it's the law. Depending on what industry you're in, sometimes you only have 72 hours after a breach occurs to notify customers. Otherwise you get hit with big lawsuits and fines from the FTC and and whatnot. My advice just like everything else in life is be as transparent as possible, especially when it comes to users private data. If you have some really sensitive private data, you need to let them know that their stuff had been taken and it's in the hands of God knows who. And especially things like, you know, make sure you tell them to change their passwords and make sure they're using something like 1password. Give them some sort of steps to make sure that, you know, their data is secure. And you can also tell them what steps you took to fix the problem and what you are going to do in the future to make sure that those problems never happen again.

So that's my thoughts on security. Like I said, final thoughts here, security, it's really just a never ending game of cat and mouse. And the biggest thing you can do as an app owner is to make sure that your development team is constantly aware of changes in the industry to security and make sure that they're doing the basics right. You can go the next, the extra mile and hire outside resources, white hat hackers, and do it without telling them and see how fun that is, and say, Here's a report, get this stuff fixed because I don't want my stuff stolen. And finally the other, if you take nothing away from this episode, take this away. Use secure passwords, unique passwords that are different from every site you use and make sure you use a password manager like 1password or LastPass. Both of those tools are going to be, you're already going to be leagues beyond most people by just using those tools. And as an app owner, they're really, all this stuff like IP whitelisting, and SSL certificate pinning, all these things are just technical terms that you as the app owner shouldn't really need to worry about. What you as an app owner really need to worry about are the things you can control, which would be using secure passwords and testing. Making sure you're pushing your team to be focused on this and make it a priority, along with all the other features you're trying to balance within your mobile app.

And that's it for today's show. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. We're also on Instagram and YouTube and Facebook and all of the socials. Show notes for this episode can be found at constantvariables.co. Today's episode was edited by the rapturous Jordan Daoust. This episode was brought to you by The Jed Mahonis Group where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at JMG.mn.