Category Archives: Computer Security

OAuth 2.0

OAuth 2.0 has been derived from OAuth 1.0. The OAuth 2.0 was introduced to remove the complexities involved with encryption of the requests for tokens that were present in OAuth 1.0 and also to make it more scalable. Some of the OAuth 2.0 providers are Facebook, Google, Amazon, Github, Microsoft, Paypal, etc. With the introduction of OAuth 2.0, OAuth 1.0 has become obsolete.

User and their roles in the system :

Here there are four users in the system, as opposed to only three in OAuth 1.0. They are follows :

  1. Resource server (same as OAuth 1.0) – A website that is capable of storing resources of users.
  2. Resource owner (same as OAuth 1.0) – An entity who wants to store his resources and can provide access to them to other entities.
  3. Client (same as OAuth 1.0) – A application or website that wants to access the resources of the resource owner, on his behalf.
  4. Authorization server – A server that provides temporary intermediate credentials  to the client, that are required in the complete process of providing authorization to the client.
How is it different from OAuth 1.0 ?

It is different in the sense that, while in OAuth 1.0 there was only one server, that is the resource server, wherein the end user (resource owner) could store his resources, in OAuth 2.0, there is one extra server in addition to the resource server – the authorization server. The authorization server is responsible for providing temporary credentials to the client that wants to access the protected resources of the resource owner. OAuth 2.0 provides for better organization and separation of responsibilities among the users of the system.

Workflow :

The following diagram that has been taken from RFC 6749 shows the workflow in the case of OAuth 2.0 .

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

The steps are explained as follows :

  1. The client that wants to access the resource owner’s resources, sends an authorization request to the resource owner.
  2. Authorization is then granted to the client by the resource owner. The authorization can be of different types depending on whether the client contacted the resource owner directly or indirectly.
  3. The client then uses this authorization grant and requests for an access token after it authenticates with the authorization server.
  4. After the authorization server authenticates the client and checks if the authorization grant provided by the resource owner is valid, it provides an access token to the client.
  5. With the access token that it received from the authorization server, the client requests for access to the resources stored in the resource server.
  6. The resource server checks if the access token is valid or not and accordingly provides access to the token.
The concept of Refresh tokens :

The OAuth 2.0 introduces the concept of providing refresh tokens. Refresh tokens are used as a substitute for access tokens that have been issued by the authorization server to the client, when the access tokens expire. When the client makes an authorization grant to the authorization server for the access token, after authentication by the authorization server, it gets back two tokens – an access token and a refresh token. The refresh token can be used instead of the access token in circumstances where the resource server finds out that the access token has expired. This helps continue the process and avoids the issue of creating a fresh access token.

Under normal circumstances (in the absence of refresh tokens) when the access token expires, the process needs to start all over from the beginning. When the client tries to access the resources by providing the access token (that was issued to it by the authorization server) to the resource server, on checking if the resource server find the access token to have expired, the client needs to begin again with requesting authorization to the resource owner and then follow it up with authentication to the authorization server again, and requesting a new access token.

The following diagram, taken from RFC 6749 explains the workflow in the case of refresh tokens.

+--------+ +-------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | |Authorization| | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +-------------+
 Advantages of OAuth 2.0 :
  1. There is a clear separation of roles and responsibilities among the different components of the system.
  2. OAuth 2.0 has support for both native and mobile applications.
  3. It supports various types of use cases depending on whether the client of confidential or public type.
  4. In OAuth 2.0, the client makes requests for tokens over HTTPS and does not require for the requests to be hashed using HMAC.
Disadvantages of OAuth 2.0 :
  1. OAuth is not backward compatible.
  2. Phishing attacks are possible.
  3. The server gets to know more information about the resources owners and clients.
  4. Denial of Service attack is possible on clients and servers.
  5. Replay attack is possible.
References :

OAuth 1.0

OAuth is an open standard for authorization and helps control access to resources that have been stored in a server, by third party users. OAuth is inspired by OpenID. On generalizing the concept of OpenID, we can see that while the OpenID is a special case of OAuth wherein the resources that are shared are only the username and password. Whereas in the case of OAuth, resources could be anything like files / photos.


Let us look at an example scenario. Suppose that Jane (resource owner) has uploaded some of her photos (protected resources) on a website – (server). She then wants to print them using another website – (client). However, she does not want to reveal her password to the server, to the client. Under such a circumstance, how does the client access her photos from the server so that it can print them for Jane ?

Naive method : A naive approach would be for Jane to reveal the password to her server, to the client so that the client can also login and access the photos. But that would mean that the client would be able to send request to change Jane’s password on the server. As the server wouldn’t know who sent the password request change, it would comply with the request.

Now this is a problem ! We need a different approach under such a situation. This is where the OAuth comes into play !

Terminology :

Some of the common terminologies used are :

  1. Server : An HTTP server capable of receiving HTTP requests from a client. In the above example, the is the server.
  2. Resource owner : The resource owner is the user who has stored some of his resources in a server and can access them using his credentials with which the server authenticates him. Jane is the resource owner, in the explained example.
  3. Protected resource : Something that has been stored in the server by its owner, and to which only limited access is allowed. The protected resource is Jane’s photos.
  4. Client : An HTTP client capable of making HTTP requests to the server. The client in the above example is
Workflow :

This is how an OAuth supporting website works in the example of Jane :

(Please note that and client, and and server, have been user interchangeably.)

  1. Jane (resource owner) has stored her resources in (server).
  2. The (client) has signed up for credentials to some of the commonly used servers (among which one is in order to provide better service to users.
  3. Jane wants to print the photos from, the client.
  4. The client needs to establish a set of temporary credentials with the server for which it sends a request for a temporary credential.
  5. The server validates the client request and sends it temporary credentials.
  6. The client redirects Jane to resource owner end of the server.
  7. The server requests Jane to sign in using her credentials that authenticate her with the server and asks her approval to grant permission to the client to access her resources.
  8. Jane approves giving access to client to access her resources.
  9. The client is informed when Jane finishes granting authorization to the client.
  10. The client requests for another pair of credentials to the server, making use of its temporary credentials.
  11. The server again validates the request and sends back a pair of credentials to the client.
  12. The client can now access Janes photos from the server, with this set of credentials recently given to it by the server.

Thus in this manner, the client is authorized to access Janes resources on the server, without Jane having to compromise her password with the client. OAuth workflow

The greatest advantage of OAuth is that it allows third party access to the resources of the user, without the user having to reveal the password. Only just enough permission is granted to the client, to access the user’s resources.

Having said that, the OAuth is not completely secure. A disadvantage of OAuth is that confidentiality is compromised. The tokens that are shared between the client and server are sometimes in plain text.

References :


What is it ?

OpenID is an open standard allows users to use existing credentials to sign in to many websites, without having to create separate usernames and passwords for each. In the system, there is an OpenID provider. The user may create OpenID account with any of the OpenID providers and use these credentials to identify themselves at different platforms. OpenID is decentralized and is not controlled by anyone.

A common example of where an OpenID is used is a passport. A person can use his passport to identify himself during the airport security check as well as to identify himself at the immigrations office or to identify himself at any other location.

Terminology :

There are three terms that used :

  1. Identity providers : They are the providers of the OpenID. A few examples of Identity providers today are Google, Facebook, Microsoft, etc.
  2. Identifiers : The number or sequence of characters (there could be other forms of identifiers too) that uniquely identify a user. In the case of the OpenID, it is a URL that uniquely identifies the user with the OpenID provider.
  3. Consumers : The parties who use the OpenID of the users to authenticate them.

 With respect to the example of the passport, the government of a country is the identity (OpenID) provider. The passport number on the passport is the identifier of the citizen, and the airport security control authorities are the consumers that check authenticate the user on the basis of his ID.

Workflow with an example :

Suppose that Alice wants to sign up in the website She already has an account with the OpenID provider Google.

  1. Alice visits the website
  2. She gets the option of either using her OpenID or creating a new username and password and she chooses to login using OpenID.
  3. The website searches for the OpenID provider that Alice specifies (which is Google in this case), and establishes an association handle with the provider.
  4. It then sends an authentication request to Google (essentially the website redirects Alice to sign into Google).
  5. Alice to signs into Google using her OpenID credentials.
  6. Google sends back the authentication response to
  7. If successfully authenticated, Alice is redirected to and has successfully logged into
Advantages :

Some of the advantages of the OpenID are :

  1. It accelerates the signup process as the user need not create a separate username and password.
  2. It saves users the headache of having to remember numerous passwords for different web sites as with the help of OpenID they can use their OpenID credentials for other websites. The users do not need to remember multiple passwords.
  3. The user can control the amount of information that is shared with OpenID supporting websites – whether they want to share only their username or their email id also.
  4. It minimize the risk when using same passwords for different websites. There are many users that use the same password for different websites. Thus if any one of these websites gets compromised, the password can be used to login into all the other websites that user has an account in. But with the help of OpenID, if the password gets compromised, it can simply be changed and the attacker would not be able to login to any other sites.
  5. The developer has advantages too. Not having to create usernames and passwords means that getting ridden from the worry of having to store them.
Disadvantages :

Some disadvantages of the OpenID standard are as follows :

  1. Decentralized : OpenID is decentralized and there is no global acceptance or standard for it.
  2. Privacy violation : Each time the user visits a site or carries out an online operation, the identity provider whose identity the user is using to identify himself, gets to know about it.
  3. Information shared : There is also the threat that your username and email id might get shared.
  4. Problem of trust : With OpenID, there is the problem of trust.
  5. Denial of Service attack : Without even having an OpenID, the user could try to log in with a fake OpenID credential. The website does not know that this is fake and sends a request to the OpenID provider. Of course the OpenID provider detects the non-existent account and denies access but already two requests have been sent – one from the user to the website and the other from the website to the OpenID provider. This in large numbers could get dangerous.

Tolerating the presence of keyloggers

The keylogger is a type of privacy breaching malicious software that intercepts the user activity and retrieves data entered by the user. This data could be used by third parties for various illegitimate purposes. Of more danger are the user-space keyloggers which do not require special permission to be deployed on a system. Recently, I read the paper, “NoisyKey: Tolerating Keyloggers via Keystrokes Hiding” that was written by Prof. Bruno Crispo and Mr. Stefano Ortolani. The paper was presented at USENIX security conference – HotSec’12 . You can find it here.

This blog post is a brief summary of what I understood of the paper.

Aim of the paper :

Currently there are a number of techniques that can be deployed to detect the presence of malicious software like the key loggers and to prevent their execution on a system. But this paper, as the name suggests, discusses how the presence of a keylogger can be tolerated.

Idea proposed :

The keystrokes that are entered by the user, travel through an event channel that transfers the keystrokes to intended application. Normally, it is this event channel that the keylogger intercepts to gain the input that has been entered by the user. In simple words, this paper proposes the idea of injecting dummy keystrokes or noise into this channel and  confusing the keylogger to believe that the dummy keystrokes are the original user input. Now the original user input will be transferred only to the actual targeted application. To list down, there are two parts to the solution implementation.

  1. Introducing appropriate dummy keystrokes into the channel in synchronization with the user input.
  2. Removing the dummy keystrokes from the event channel before they reach the actual application.
Components of the solution :

The solution has itself been implemented in a library named silencer.dll. The following are the four components of the solution implemented :

  1. Noise factory : As the name denote, this is component that creates the dummy keystrokes or the noise.
  2. Injector thread : This component takes the noise that has been generated by the noise generator and introduces it into the event channel.
  3. Normalizer : The normalizer plays the role of shaping the noise that is injected into the channel. It is the intermediate component between the noise factory and the injector thread. As the paper mentions, this is important so that the keylogger does not come to know that it is receiving dummy data. For example, take the case where a user is needed to enter an only digits containing key or pin. The keylogger would be expecting digits. In such a case, it is the role of the normalizer to introduce only “context-aware” noise, as the paper puts it across. It produces context-aware noise by analyzing the past keystrokes.
  4. Silencer : This is the library in which the solution has been implemented. It is the duty of the silencer to work in synchronization with the injector thread.
Workflow :

The workflow has been explained with Windows operating system in mind. The noise factory has a set of dummy keystrokes ready with it, which are transferred to the Normalizer. The normalizer makes sure that the noise is correct with respect to the current context of the event that is getting intercepted. Now when the user enters data, keystrokes travel through the event channel. As soon as the user inputs a keystroke, the process – csrss.exe gets alerted. It is the duty of this process to transfer the correct user input to the destination application. Another application that gets alerted is the silencer thread. The noise is then passed to the injector thread that introduces the noise into the channel. The injector thread notifies the silencer thread about the injection of noise. The silencer removes the dummy keystrokes before they reach the intended application.

This way, it is made sure, only the targeted application receives the user input and not any other application, be a keylogger or any other piece of malicious software.

Other sources :

You can listen to the presentation of the paper here.