I Don’t Want Just Anyone To See My Data

--Originally published at Debugging My Mind

Confidentiality as I’ve mentioned before, is a key property that any application must have, you don’t want your personal data that any app you download so easily asks for to be out there for anyone to see, otherwise we would just be carrying around papers with all our info taped to our backs.

This is why as developpers we have to always assume any info we ask out of someone about them can be personal, we don’t know whether someone thinks their name can be public, or someone who thinks it should be kept private unless absolutely needed otherwise, so it’s better to keep things as confidential as possible by default, rather than publicly out and easy to obtain.

One of the main methods to keep confidentiality of data we have stored of our users is by the use of encryption. Using a hashing algorithm we change that plain text info into an unreadable mess that requires computation to solve, adding salt and pepper we make it very difficult to go back to the original text without  the key, making it so that data cannot be precomputed in bulk as a rainbow attack.

Handling data of young children makes it even more sensitive, as their personal information is being handled by other people that have to be responsible for it. This wasn’t an issue back when we were younger, but these kids live in the digital age, where the internet is predominant and their info can easily be thrown out there for anyone to see without their consent or them even knowing. It wouldn’t be nice us as adults right now to find out that back when we were young and couldn’t do anything about it our information was put out there easy for people to find and read.

It’s for this reason that it’s better to assume all data related to our users as sensitive, be it their name, age or gender, and keep things encrypted and with needed authentication to access, since their confidentiality and the app security is our responsability as developers.


What Happened With My Data?

--Originally published at Debugging My Mind

Integrity. The property of data not being altered or destroyed by an unauthorized entity; such a property isn’t so easily assured to a client, and that’s why we needed a plan as to how we were gonna do it.

Our application consists of 2 separate main modules, the school management part of the app, consisting purely on the web implementation, keeping track and being able to register teachers, students and checking on their information, while on the other side we have the game itself, responsible of handling all the logic to provide the levels, with their defined difficulty, as well as keeping track itself of temporal progress data from each student.

Our main concern related to data integrity surged from the communication between these modules, more specifically, between the game and the database, since there has to be a stable connection to be storing each separate level, as well as obtainning the new predicted difficulty for the game, there is a chance of data being corrupted or lost in the process should a connection error occur.

Because of the glaring problem that the lack of connection of the game with the server creates, we decided to design the game itself in such a way that it can work independently whether there is a connection to the database or not. To do this, the game will do several checks before starting: first, it will try to connect to the server to obtain the user’s required information, such as their profile, predicted new difficulty and money for the store, should this connection fail there will be 2 options. One of them is executed if there are no locally stored information, where the game will begin in a “default” mode, where the player plays through the game as if they started back from 0, allowing the game to be played even if there are technical difficulties with the server. The second option is to load locally stored data, this means that the game will not only save data to the server itself, but also store data in the computer that is played in order to be used offline, this would disable the automatic difficulty prediction of the game, but would allow a player to continue playing where they left off.

Once connection is re-established with the server, the game would utilize the offline data to continue the gradual difficulty it had stored and send it all together back to the server, in order to create an accurate new prediction of difficulty for the next session. This is done so the progress that a student has made offline isn’t just discarded, and that the old difficulty prediction isn’t used as the local one might be way different at this point.

Going deeper into the database, we have a set difficulty for each player’s profile, generated from the average results from the previous levels played, this means that in the case that level specific data is lost when saving, the difficulty where the player is at itself is kept intact, allowing such risks to take place without causing damage should they happen.

Another mechanism we had thought of as some kind of backup for the player’s difficulty, was some kind of seed that would save the difficulty setting in a small and simple string, although, this wasn’t possible to implement due to time restrictions, and remains as an idea for future implementation.

The idea of backup is a safe way of keeping data integrity even in extreme scenarios of technical and hardware failure, but this kind of solution requires resources like money and time, as there is the need of separate drives where the backups need to continuously be written, as well as taking the time to make sure that they actually work.


Let’s Get Paranoid

--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.

Security

Image by Henri Bergius

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.


The Security Triforce

--Originally published at Debugging My Mind

security triforce

It is said that if you gather all three pieces of the security triforce, your software will be the most protected. In all seriousness, this is known as the CIA/AIC security triad and it refers to the most common topics that are focused on when protecting systems. It refers to Confidentiality, Integrity and Availability.

These next months my team and I will be creating a web application focused on helping the 2nd grade students of a particular school, where security will become a topic of importance for the development of this app.

At first glance you might be able to discern what these 3 terms mean from the word alone, but I’ll go through them quickly and specify what they represent, as well as how each of them will (or not) be necessary on the app that we’ll be developping.

confidentialityConfidentiality: It refers to the ability and the property of keeping delicate and important information hidden or encrypted in such a way that unauthorized individuals are incapable of accessing it, and even in the case of it happening, being unable to understand it.

In order to customize each of the children’s experience with the math mini-games we’ll be implementing in the application, as well as the reports the teachers will obtain, delicate and important information about them might be needed and stored within the app’s database.

Since the personal information of young children will be handled, we have to be very careful to keep it as confidential as possible, as well as making sure to not keep data that is no longer used (for example, children that have left the school or that just won’t be using the application anymore shouldn’t have their data kept after some time has passed). I believe this specific security property is the most important for this project, these children may choose to provide their information to specific sites or applications of their own will in the future, but today this is a choice made for them, and one that can’t be taken so lightly as to carelessly handle their information.

integirty

Integrity: This refers to the importance of data not being altered or destroyed by an unauthorized entity, may it be through the modification of a file, or a change to the system’s configuration. Usually this is found when a file is infected by a virus, or when data is modified mid-way transit through the network, like an email on the internet.

In this case, integrity doesn’t become a property of huge importance for our application, while there are still some measures to be taken, the system will be constantly storing and modifying the data used to customize the exercises for the students, so the corruption of one of these does not become a big deal as it will soon be replaced by another based on the children’s performance.
availabilityAvailability: As the name implies, this property refers to the ability of the system to continue being accessible even if there is an error or corruption of data. This is usually achieved through redudnancy so that if a piece of hardware fails, another one can take over for it and keep the system running and usable.

For our application and due to the limitations in hardware and resources available to us, achieving redundancy and constant availability can be complicated and something down the priority list. The biggest solution we can provide is hosting the application on a separate hired server, not hosting on a school’s computer which can lead to a hardware malfunction. While a hired server (like Amazon Web Services) give us the so liked and wished constant availability and a fault tolerant system (most of the times at least) , this requires a constant fee that ends up being up to the school if they decide to adopt or not.

All in all, regular users of software won’t have this triad in mind when using it, often taking things for granted, we as software engineers have to be careful and make sure our designs and implementations come as secure as possible (what our resources and abilities allow), and most importantly, have all of these features work by default. The default setting should always be the secure option.