10 Security Concepts Developers Need to Master

“You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I’m offering is the truth. Nothing more.”
Morpheus

From the moment I became a professional developer, I started creating code to handle authentication and authorization in applications. Life was so simple at that time! Usernames and passwords were restricted to five alphabetic characters, the colors on the display were only amber and black, and the number of computers on the network was one: the mainframe. Access to the data center was restricted and there was no such a thing as the Internet available.

Although some of the security concepts we use today were recently created, most date from long before. People have always had the need for taking measures to guard against attacks and crime. Ancient people survived by protecting themselves and their group against animals, weather, or other rival groups. Precious resources had to be guarded, secrets had to be kept safe.

Nevertheless, when we take a modern technical text about application security, everything seems so complicated we sometimes think: “I am never going to get it. I need to be a rocket scientist to understand how it all works together!” Modern security systems are built with many layers of complex software, involving so many concepts and technologies, that they boggle developers’ minds and cause a lot of frustration.

It is common wisdom that in order to understand complicated things, we need to break them down into smaller parts. If you want to understand complex security systems, you first need to have a good grasp of the basic security concepts, so let’s begin from the start:

1 Resources

If there is a need for security, there is something that needs to be guarded. That “something” is what we call a resource. This may be the interior of your house, the money in your bank account, the information in your private journal, or even some digital thing, like the pictures in your phone, or your Facebook password.

2 Principals

If there is this something, the resource, that needs to be secured, it is only logical to assume there must be someone trying to obtain it. That someone is called the principal. For example, when you come home after a long day of work, you will want to access the interior of your residence. The interior of your house is a resource. You are the principal. In computer systems, the principal can be called by many names, like user or client, but the important thing here is that you understand the concept. If someone tells you “the JavaScript client library makes an Ajax request to obtain the access token” and you somehow understand that gibberish, it is important that, in your mind, you can simplify things to a point where you say to yourself: the principal is trying to access the resource, nothing more than that.

3 Identities and Credentials

When a principal tries to access a resource, the first thing our “security system” needs to do is to verify if the principal is who he or she (or it) claims to be: to check the principal identity. In order to have the identity checked, the principal will provide credentials. In the real world, it can be a badge, or a photo id. In the digital world, it is commonly a user id and password, but not necessarily.

4 Authentications

If your security system is a lock on your front door, the way it will verify the identity of the principal is by confirming he/she/it has the right key that opens the lock. There are three possible factors used to authenticate a principal: the principal has something, or knows something, or simply is something that is recognized and permits a positive identification. If your security system is your dog, it will grant you access by acknowledging you by who you are: your image, your smell, your voice, etc. The lock, on the other hand will only require that you have one thing: the key. When more than one of these factors is required, we call it multifactor authentication: let’s say you have a lock and a dog, so you need to have a key and you need to be you.

5 Claims

Because the principals claim to have a known identity, all the things and information provided by the principal are usually also called claims. Sometimes, in computer systems, claims are also used to designate all information the application knows about the principal.

6 Rights

So far so good, you come home, you have your key, and your dog did not forget who you are. You have been granted full access to the wonderful resource that is the interior of your house. Who granted you that? Your security system: lock and dog. Well, this very simple security system assumes you can do anything with the resource. Full access, because you are the owner. You can use the objects in your residence, and even take them with you to wherever you want. Doing anything, or full access, are the rights you have in relation to the resource.

7 Roles

You have these rights because, for the security system, you play the role of “owner”. The rights are usually associated with the role, but on some systems, they are associated with the principal directly. Principals playing other roles can have different restricted rights. For example, let’s say you have a lock, a dog, and a spouse at home as components of your security system. Another principal, this time a cleaning lady, comes to your residence. She has a key, the dog and your spouse recognize and trust her, and so she is granted access to use some of the resources. She can enter, she can use appliances and bathrooms, cook, but she is not allowed to sleep over or to take home objects with her. Those are rights that were not granted to the role “cleaning person”, so your spouse would not allow it to happen.

8 Authorizations

The process of granting the correct rights to a principal, based on the inherent rights or roles is called authorization. This is exactly what happens when you withdraw cash at an ATM. You want access to a resource: money from your bank account. The money and the bank account are resources. You are the principal. The ATM security system requires you to insert your card: this is an authentication factor, something you have. Then it asks you to enter your account Personal Identification Number (PIN) on the keypad. This is another authentication factor, something you know. If the system recognized the card and the PIN as your account PIN, you are first authenticated and then authorized: the ATM system grants you rights, in the role of “ATM user”. Then the system will check what are your rights for this role and this resource, and then it will display a list of options on the screen. If you are authorized to withdraw cash, it will display that option.

9 Threats

We better face it. If we need security, it is because there are threats. If nothing bad could possibly happen to our resources, there would be no need to explain the concepts in this post. Threats are exactly these bad things that can happen. Our possessions can be stolen, our home destroyed, our lives taken. Any danger is a security threat, no matter if intentional, accidental, or natural. In the cyber world, we try to classify these threats in six categories: Spoofing, Tampering, Repudiation, Information disclosure (or data leak), Denial of service (DoS), and Elevation of privilege. You can remember these using the acronym STRIDE, but this cyber threats classification is material enough for another post.

10 Vulnerabilities

A vulnerability is a weakness that can be exploited. In computer systems, there are lots of vulnerabilities in many different categories: hardware, software, network, personnel, physical access, organizational, etc. There are so many vulnerabilities, in fact, that I will address them a few at a time, in multiple posts, so I don’t scare you from the beginning. Little by little, we can learn to patch most of them, but in order to do that, you will have to choose the red pill and open your eyes to the hard and cold reality of how much our systems are vulnerable.