--Originally published at Debugging My Mind
Everyone is out there to hack you and get your personal/private information! Well, maybe not everyone, and maybe it won’t be happening to you at all in the course of your life (or at least not without you noticing), but this is a real danger that comes with the use of technology, specially the internet, where it’s so easy as to start a blog like this one and write off of your mind without a care in the world.
So as an user you hear the usual stuff, “Get an antivirus”, “Use different strong passwords for your accounts”, “Don’t click on the DOWNLOAD HERE links or enter your credit card information to win the amazing prize you just got in this random website“, but even if you were to follow all these pieces of advice you keep hearing around related to security, you might still lose access to an account or your information taken, and this is where not only the final user has to take their appropiate security measures, but where our job as software engineers begins.
What good is there that our users take several extra steps to care for their security if the software we create has a clear fail, an easy backdoor to access, and then when the information gets taken, it’s as clear as plain text, which they can then use as a domino effect to cause more damage to us and our users.
Here’s where the title comes in, let’s get paranoid, not only about our security as users of a piece of software, but as developers of it. Things like security are often taken as an “opt-in” mechanism, cutting the corners and the extra work that it takes to add a probably already tested and reliable library that creates a new layer of security, mostly because the sole research of the method seems like an unknown monster to tackle, you don’t know if it’s gonna be easy or tough, so we just choose to ignore it.
This is where having all the horror security stories help so much, to get scared, get paranoid in such a way that we realize how, adding more and more of those low-cost security layers (which can be also actually easy to implement) make it harder and harder to make our application a target to attacks, sure, we can’t promise that it’ll be the most secure, or that it will be impossible to breach, but most of the things that hackers try on their targets are first and foremost the simple attacks, the easiest and most obvious ones they can think of. They’re not gonna try to pull of a super complicated and convoluted attack out of the blue, if you were gonna try to enter a restricted area/room, wouldn’t you first check if the door is actually locked? it’s kind of the same principle, and the reason why adding those simple extra layers of security is so important, we gotta in the very least make it a bigger effort for them to enter the room.
An example of this is encryption, instead of encrypting the “sensitive data” why not encrypt practically everything, it’s cheap, it’s easy if you’re doing it already with some registries, and you can add salt and pepper to make it even more secure even if they were trying to rainbow attack your encrypted tables.
There is a real issue with adding too much security, which is the trade off of usability that we’ve mentioned before, the more layers you add, the harder and more time consuming it actually becomes to access and use your software, which is a conscious decision you gotta make depending on what the goal of your application will be.
In our case, where we’re currently developping a web application for elementary grade children to help them practice and reinforce their math knowledge, there are certain things to take in mind. While we don’t store much sensitive data about the children, we’re highly responsible about it, since they themselves don’t even know their own personal information is being stored in a place that can possibly be attacked and stolen from, and putting it out there on the internet, we have to make sure that such a thing is very unlikely to happen. For example, going back to my earlier recommendation, we’re gonna have to encrypt all the data we store, even if it isn’t sensitive one, better safe than sorry right? better be paranoid.
On the other side, we’ll need to handle authentication for the different level users, we don’t want a student to be able to access the teacher’s records and data, nor do we want a teacher to be able to see outside their group as it isn’t needed. Different roles with different levels of authorization will be needed to manage the web application, handled through their very own accounts with passwords (which then goes into the whole issue of closing their session if it’s being inactive for long enough, avoiding yet another problem).
While it’s true that there are more thing we can do to make our application safer, there is also the short amount of developping time we have to deliver the final product, which means we have to choose what precedes in importance and what we can or cannot add to development.
In the end I do believe one of the goals has been met, I for one, have honestly become way more paranoid, and while I don’t mean this in the wrong way, like I won’t be losing any sleep or being constantly anxious, security is a real thing that keeps going through my mind in the daily use and making of software, and I think that’s one of the most valuable things I’ve gotten from the security course.