Basics of software security: Authorization

This is the second post of a small series about the seven key software security goals. It doesn’t apply only to software security, but security in general. Traditionally there are six elements on this list: Authentication, Authorization, Confidentiality, Integrity, Accountability and Availability. DASWANI, KERN and KESAVAN mentions a very interesting seventh goal: Non-repudiation.

Authorization

Authorization is about checking if someone is able to perform an operation on a resource. In other words, after we know who the user is (authentication), we need to know if it has permission to do what it wants to do.

Usually the concept of resource is tied to the authorization process: the user is trying to perform an operation on a resource, it could be reading the resource, it could be modifying it, etc. Normally the user is also tied to one or more roles (e.g. admin, normal user), so, instead of checking if the user is authorized to perform an operation, we check if its role is authorized.

Let us draw this concept in an example: let’s say Mr. Daario works as a seller in a department store. He has a user and password on this store’s inventory system. After logging into the system, he tries to create a promotion for a product, but the system denies it, saying that Daario can’t create promotions. This means Daario was successfully authenticated to the system, but he wasn’t authorized to add a promotion. Daario can check what are the current active promotions though. Now, lets say Mr. Barristan is a manager on this store. He, after typing correctly his user and password into the system, can successfully add new promotions. He can also visualize existing promotions and even suspend a promotion if he feels like. What we can tell from this example is that the role seller can only visualize promotions, and the role manager can create and suspend promotions, in addition to visualize them.

Sometimes is not required for a user to be authenticated, so an anonymous or guest role is given to this user. Usually these are very limited roles – since anyone can have it – but it fits very well is some situations. For example, to visit a webpage, you don’t need to create a new user account; so is given to you a guest role, which allows you to see this webpage, except the sections that require a more privileged authority. Furthermore, the guest role could be the only one authorized to see ads on the page, this would stimulate guests to register an account and get a “basic user” role, which would not be authorized to see ads.

References

Neil DASWANI, Christoph KERN and Anita KESAVAN: Foundations of security: what every programmer needs to know.

J. D. MEIER et al:  Improving Web Application Security – Threats and Countermeasures.

in Everything else | tagged ,

Basics of software security: Authentication

This is the first post of a small series about the seven key software security goals. It doesn’t apply only to software security, but security in general. Traditionally there are six elements on this list: Authentication, Authorization, Confidentiality, Integrity, Accountability and Availability. DASWANI, KERN and KESAVAN mentions a very interesting seventh goal: Non-repudiation.

Authentication

Authentication is to verify someone’s identity. To make sure this person (or application) really is who it claims to be. The goal is to identify, in a unique way, an entity interacting with an application. This entity can be a person or another service or application. Usually authentication is performed by combining three methods: something you know, something you have, and something you are.

Something you know

This is the most common and elementary method. A password is something a user knows. It could be considered the most simple method to implement authentication. For entities using your system, it is also very simple for them to understand and use it.

The disadvantages of this method match a very interesting concept brought by DASWANI, KERN and KESAVAN: the eternal struggle between convenience and security. Basically, the more security you have, less convenience for users. Since something you know is a very simple (therefore convenient) method, it is also the easiest to break. Specially if weak passwords are used. You can enforce stronger password policies, it will be less convenient for users, but it’ll provide stronger security. But still weaker than other authentication methods, or weaker than combining methods.

Another way to improve this method (and again, consequently decrease convenience) is the use of one-time password systems (OTP), which forces the user to know multiple passwords in a pre-determined list. Each time an authentication operation is performed, the user is forced to provide an specific password from this list. Even if an attacker discovers one of the passwords, it will be more difficult for it to determine what is next on the list.

Something you have

This can be stronger than the previous method when talking about software authentication. The authentication is based on something physical only the user possesses.

My favorite example is the use of OTP Cards: the user keeps a device (or, lets say, an app on his/her smartphone) that generates a password based on an algorithm known by the application. To increase security, usually this password has a very close expiration date (no more than a couple of seconds). The algorithm allows the application to know when a password is not invalid anymore. Variations of this method include direct communication with the authentication server for generating salt codes on demand, in order to protect the user in case an attacker somehow manage to generate valid codes.

ATM cards people use on teller machines are another example of authentication based on something you have, except this time no code is generated, but the teller machine reads the magnetic stripes on the card (not to be confused with Smart Cards).

This method really gets powerful when combined with others. Combining something you have with something you know makes it way harder for an attacker to authenticate on your behalf. Lets say an online service, after successfully authenticating an user based on a password, also prompts the user to insert the code generated by his/her OTP card. This is the term known as two phase authentication (or two-factor authentication, two-step authentication, etc), in which we have multiple secured steps to perform the single event of authentication. Even if an attacker discovers the password and successfully passes trough step 1, it will never authenticate unless it takes hold of the OTP card.

Something you are

This method is about identifying an user based on some of his/her unique characteristics. This usually leads to biometric techniques. REID defines biometric technology as something that uses a physical or psychological trait for identification and/or authentication. Iris scan, hand scan, fingertip scan and voice recognition are valid examples of biometric authentication based on something you are. Other methods include facial and signature recognitions.

This is usually the most complex method to implement, and still too prone to failure. Sometimes there are also social acceptance issues when trying to implement this method. Another big problem with biometric authentication is key management: when an user password gets compromised, we can always generate a new one. But if an attacker gets hold of the data that represents, lets say, someone’s fingertips, we can’t just generate a different one, since the fingertips are still the same.

References

Neil DASWANI, Christoph KERN and Anita KESAVAN: Foundations of security: what every programmer needs to know.
J. D. MEIER et al:  Improving Web Application Security – Threats and Countermeasures.
Paul REID:  Biometrics for Network Security.