Security Comparison

Challenge-Response Token

Challenge-Response Token is widely accepted in Indonesia as a de facto Security Token technology for many years, until Zeus attack as man-in-the-browser with it’s famous “sinkronisasi token” screen to the 2 largest bank in Indonesia.

Challenge-Response Token is very secure in term of technology, but it is weak against social engineering in internet banking, because of 2 reasons:

1. Challenge-Response Token is built to authenticate the user, not the bank.   The user never knows whether he/she is looking at a valid internet banking portal screen or not.  The Token was just used by the bank to check whether there is a valid user on the other end.
2. Challenge-Response Token is mainly built for authentication, not authorization.  That’s why the user don’t see any business context on the Token’s screen, the token screen doesn’t say anything about the purpose of the authentication.

And now the big question, what if the client’s computer infected by man-in-the-browser?  It would be as follow:

1. Customer can’t be sure whether he/she is looking at a valid internet banking portal screen or not
2. Customer don’t know what does the OTP code used for
3. Customer don’t know what does the Challenge-Response code used for

 

Digital Signature Token

Digital Signature Token is new in Indonesia market, but it has been widely used in the world, including world’s largest bank such as ICBC in China.

Digital Signature Token is very simple and convenient to use, because it just have “OK” or “Cancel” button, therefore the customer doesn’t need to type any complicated number on the Token.  Despite it’s simplicity, Digital Signature Token is a digital fortress that can protect the customer from advanced security threat including man-in-the-middle or man-in-the-browser attack, because of 2 reasons:

1. Digital Signature Token helps the user to authenticate the bank.
   •  The Bank can send token screen with digital signature (using Bank’s private key) to describe the activity it will perform
   • In case of the client’s computer has trojan/virus like man-in-the-browser, it can’t send a fake token screen because it doesn’t have the Bank’s private key
   • The Token will validate the digital signature (with Bank’s public key) before showing it on its screen.
2. Digital Signature Token is built for authentic authorization.
   • The user can see clear token message on the Token’s screen, and decide whether he/she want to approve or cancel the requested activity.
   • The activity that the user choose (OK or Cancel) will signed (using device’s private key), and sent to the Bank.  Therefore a trojan/virus can’t send fake authorization because it doesn’t have the device’s private key.

And now the big question, what if the client’s computer infected by man-in-the-browser?  It would be as follow:

1. The customer can authenticate the Bank by comparing the message on computer screen with token screen.  If the computer is infected with man-in-the-browser, the computer screen will not match the token screen.  However, the token screen is digitally signed by the bank, thus it can’t be altered by man-in-the-browser.
2. Customer can see on the token screen, what is the real activity that requested to the bank.
3. Customer can decide whether to authorize the requested activity or not.