Video Screencast Help
Security Community Blog

Facing authentication threats: one time passwords and transaction signing

Created: 28 Mar 2013 • Updated: 28 Mar 2013 • 3 comments
Antonio Ricci's picture
+1 1 Vote
Login to vote

Authentication is one of the oldest problems of the information security, and it is always a living matter. Getting a user password is the easiest way to gain access to critical systems, steal confidential information, etc. And this is why attackers are really interested in stealing passwords. The evolution of information security brought several technologies to improve the protection of user authentication systems, but at the same time attackers improved technique and tools to steal valuable information. Not always attacks are based on technology and software. In most cases the easiest way to get a password from a user is asking. This is not a joke. Unfortunately this is the reality. Social engineering techniques evolved during the time, and nowadays a smart attacker can cheat a user telling him he needs is password to complete his work, or to fix a broken system. And this is just an example of how attackers get the password from users without using sophisticated tools. 

When social engineering is not enough software is always ready to help an attacker. There are different attacks based on software. Among these we remember:

  • brute force attacks
  • password reply attacks
  • man in the middle

From now on I will focus on user authentication to web portals (e.g. banking systems) that allow users to complete online transactions. This is a very common scenario but not always applications protect users' information properly. Let’s see some solutions to this problem. We will cover the banking scenario, but the same solution can be applied to several applications. 

Consider a banking system that authenticates user with username and password. This is what we call Single Factor Authentication. This is really straightforward for users. We all use usernames and passwords every day. But this authentication technique is really easy to be attacked through technical (man in the middle, password bruteforcing, etc.) and social engineering attacks (phishing, shoulder surfing, etc.). This is why most banking system added a second factor of authentication. Second factor can be something that belongs to the user or something that is part of the user. The latter can be a fingerprint scan, iris scan, or something behavioral (e.g. how fast the user writes his password). These techniques are not often used in banking system, because are expensive and invasive on user experience. 

The most common second factor using by applications is what is often mentioned as “something you have”. This is usually a numeric code that can be either generated by a one-time password system or read by the user from a matrix of authentication numbers. There are several way to generate one time passwords, some of them based on proprietary algorithms and other based on public available standards. Usually we distinguish two different type of token:

  • Event based
  • Time based

The first family of tokens increase a counter and generates a one time password when a specific event happens. Time based tokens update a counter on a given frequency (e.g. 30 seconds) and provide a one time password valid for that time frame. Authentication based on this type of OTPs are very common in several scenarios like web applications, VPNs, etc.

2-Factor authentication is an effective technique to mitigate risks related to password oriented attacks. As attackers are evolving their techniques some advanced malware can be able to cheat the user to introduce both factors on fake websites and act as the user. When we are facing with transactions it is possible to block these attacks using transaction signing. Transaction signing calculates a value based on the user input on client and server side. Only if the values correspond the transaction can continue. Let’s say that Alice is connected to her banking portal to  transfer 1000$ to Bob. When Alice clicks confirm, the web application sends all the information to the bank that calculate a challenge (let’s say 383) based on Bob account information, transaction amount and a shared secret. At the same time Alice calculates the same value using a tool (like a calculator) provided by the bank and she submit it on the banking portal. If the 2 values correspond the transaction is confirmed. 

Let’s see what happens if Joe is an attacker that intercepts Alice’s request and change it before sending to the bank. Alice asks the bank to transfer 1000$ to Bob. Joe intercept the request and change it to “transfer 1000$ to Joe’s account”. When the bank receive the request it seems that Alice is going to transfer 1000$ to Joe, but Alice believes she is sending moneys to Bob. Now the bank calculate the challenge based on the following information:

  • Amount: 1000$
  • Recipient Account: Joe

Alice calculate the challenge using the following:

  • Amount: 1000$ 
  • Recipient Account: Bob

The requests are different, so they will produce different challenges. When Alice will send her challenge (let’say 383) to the bank, they will compare it with the calculated challenge (let’s say 385, calculated on Joe’s request) and the transaction will be cancelled. 

Even if Joe tries to intercept the request from Alice and modifies the challenge he won’t be able to create a proper challenge based on the information he provided. The challenge is calculated with transaction information and a shared secret between the bank and the client. 

The scenario described above can be implemented through a standard defined by IETF and known as OCRA (OATH Challenge-Response Algorithm). OCRA has several more features than the ones described in this post and can be extended to multiple scenarios.

Symantec 2 factor authentication services support One Time Password authentication through several types of token (hardware and software based) and  OCRA to implement transaction signing as described above. In some scenarios the OCRA calculation can be executed using an ad-hoc application running on a PC or on a mobile device (tablet, mobile phone). Usually OCRA calculation is executed out of band on a device different from the client connected to the banking portal.  This avoids attacks where a malware can intercept both the transaction request and the challenge.

 

Comments 3 CommentsJump to latest comment

Tariq Naik's picture

Nice and crisp artcile. Is OCRA beeing used by any banks? How is the adapatation?

0
Login to vote
Antonio Ricci's picture

Hi Tariq,

while OCRA and transaction signing are not often used by banks currently I believe that in the near future we will see most banks adopting these solutions. As for today transaction signing (and its implementation through OCRA) is the better solution to malware in the middle attacks. The main limitation to transaction signing adoption is the impact on end users as the transaction will be a bit more complicated. I have been working with some banks to evaluate how to integrate the OCRA transaction signing within their mobile applications in order to keep an high level of security without a negative impact on end users. We are still working on this.

Opinions expressed are solely my own.

 

0
Login to vote
VoiSafe's picture

Thank you for the article, Antonio.

Would you please explain why Joe, the attacker, won't be able to block Alice's messages to the bank alltogether (post authentication), presnt to her a facked UX and communicate directly withthe bank to carry a transaction. That is to say that the bank never gets Alice's request to transfer to Bob. Bank only get the request to transfer to Joe and from there, bank generates challenge for Joe. Joe respond to that challenge; not Alice.

Is there someting that only Alice have (such as biometric feature) that Joe can never have to generate a response? 

 

Regards,

Dror

0
Login to vote