Authentication AND Authorization

Code security protects the normal, day-to-day operations of an app, tool, or daemon. But what happens when your code is under siege? It is often essential to know not only what the user is doing but also who the user is and whether the user is allowed to do that. This is where authentication and authorization come into play. In simply Authentication verifies who you are Authorization verifies what you are authorized to do.

When we aimed to the area of user authentication then we can identify that there are three types of user authentication types. They can be named as;

• 1.       What-you-know.
• 2.       What-you-have.
• 3.       What-you-are.

What-you-know

The idea here is “what you know” a secret --- often called a password --- that nobody else does. Thus, knowledge of a secret distinguishes you from all other individuals. And the authentication system simply needs to check to see if the person claiming to be you knows the secret. Otherwise, once that information falls into the wrong hands, a "game over.

Passwords are the original and most widely used authentication technique, but also the easiest to crack. Even if a password is not trivial to guess, it might succumb to an offline search of the password space. An offline search needs some way to check a guess without using the system itself, and some methods used today for storing passwords do provide such a way.

When passwords are used for authenticating a user, the system must have a way to check whether the password entered is valid. Simply storing a file with the list of usernames and associated passwords, however, is a bad idea because if the confidentiality of this file were ever compromised all would be lost. (Similarly, backup copies of this file would have to be afforded the same level of protection, since people rarely ever change their passwords.) Better not to store actual passwords on-line. So instead we might compute a cryptographic hash of the password, and store that. Now, the user enters a password; the system computes a hash of that password; and the system then compares that hash with what has been stored in the password file.

Even when password hashes instead of actual passwords are what is being stored, the integrity of this file of hashes must still be protected. Otherwise an attacker could insert a different hash (for a password the attacker knows) and log into the system using that new password.

The problem with having a password file that is not confidential -even if cryptographic hashes are what is being stored -is the possibility of offline dictionary attacks. Here, the attacker computes the hash of every word in some dictionary and then compares each hash with the stored password hashes. If any match, the attacker has learned a password.

What-you-have

The next level of protection validates users based on things in their possession, physical or otherwise. This can sometimes take the form of USB drives or smartphones.

In the case of mobile device usage, one-time passwords can be an effective solution. One-Time Password (OTP) Authentication products generate highly secure one-time passwords ensuring that only properly authenticated users are authorized access to critical applications and data.

OTP solutions first took the form of code generators and plug-in tokens that authenticated users with random codes on top of their personal passwords. But this method has taken a new step thanks to text messaging and mobile applications. OTP’s can be sent to smartphones and tablets upon the successful input of user-generated alphanumeric, meaning that even if passwords are obtained by malicious parties, there is still little that can be done with them without the user's personal device. This is why credential delivery is much more viable and secure than singular passwords. For example see the following figure what we met when we log in to Gmail.

A similar means of protection takes the form of public key cryptography. It is also one of the strongest methods of password security. For PKCs to work, a digital certificate is issued to users by verified third-party certificate authorities. These certificate authorities manage public key infrastructures, where those wishing to log in to a specific service must match private keys - stored in physical hardware tokens - with the public certifications they correspond with.

What-you-are

Since people forget things and lose things, one might contemplate basing an authentication scheme for humans on something that a person is. Therefor the third type of user authentication uses biometrics and is termed what you are. It is common to find user authentication systems that combine above approaches. For example, your bank ATM card (something you have) and the PIN number (something you know) is one such combination.

Authentication based on "what you are" will employ behavioral and physiological characteristics of the principal. These characteristics must be easily measured accurately and preferably are things that are difficult to spoof. For example, we might use

• Retinal scan
• Fingerprint reader
• Handprint reader
• Voice print
• Keystroke timing
• Signature...etc.

To implement such a biometric authentication scheme some representation for the characteristic of interest is stored. Subsequently, when authenticating that person, the characteristic is measured and compared with what has been stored. An exact match is not expected, nor should it be because of error rates associated with biometric sensors.