printer friendly version

Authentication tokens - a response to the challenge of Internet banking fraud

The best way – at present – to reduce the risk of Internet banking fraud is through the widespread rollout of secure authentication tokens. These, used in conjunction with a challenge-response scenario, could go a long way to prevent the kind of online banking scams that hit South Africa last year and regularly make headlines around the world.

Secure authentication is the process by which your bank or financial institution verifies that you are who you say you are. Today, electronic banking systems can authenticate a user by examining three criteria: what you have (eg, your banking card), what you know (eg, your password) and what you are (eg, biometric scanning of your fingerprint or retina). Systems that utilise all three factors are inherently more secure than those that only make use of one.

This is where the problems with Internet banking arise. Although card readers as well as biometric devices are available for most PCs and laptop computers, they are not widely used by the general online banking client. As a result, user authentication within the Internet banking domain is limited to what you know - your password.

Because Internet passwords today are based on static data - the user enters the same password each time he or she logs on to the banking website - hackers can record passwords while they are being entered and can then use them to gain fraudulent access to Internet banking accounts. Using dynamic passwords for online authentication would serve to close this particular loophole in the security system.

Using dynamic data for passwords

Broadly speaking, dynamic data authentication involves the use of a secure authentication token that allows Internet banking clients, in unison with back-end banking systems, to dynamically generate a new password each time an Internet banking session is initiated.

Since this password changes from one session to the next, there is no value in hackers attempting to record it.

Key to this process is the secure authentication token, which usually takes the form of a small handheld device and which comes with or without a keypad and smartcard reader. Using advanced encryption techniques, these tokens provide Internet banking users with access to the same unique log-on passwords as that generated by the back-end banking system. In this way the legitimate banking client and the bank are always in sync.

Generating passwords without the use of a smartcard

But not all authentication tokens are equipped with smartcard readers. Where tokens do not have access to smartcards to assist with the password generation process, both the end-user, customer device and the back-end banking system must have access to the same set of encryption techniques, security keys and data. The data used will often include time as well as a counter that is linked to the 'number' of the particular password being created.

Using this information in the same way as the token, the bank can generate the same dynamic password as the customer device and can compare the two to authenticate the user.

One major drawback with these types of dynamic password devices is that they can get out of sync with back-end systems. If a user mistakenly creates a password and does not submit it, the system will fall behind the device. The next time the customer wishes to log on to his or her Internet bank and submits the information provided by the token, the bank will deny access as it will not be the same as the information expected by the back-end.

Another issue relates to the use of time as a data element in the creation of the password. If one considers the time delay between a customer generating a password and sending that password to the back-end system, it becomes apparent that a reasonable time-window needs to be allowed to ensure that the back-end can generate the same number as was submitted.

To prevent Internet bandwidth and slow message delivery from causing problems, time windows have to be increased. However, as these become larger, so the door for hackers to capture and replay passwords starts to re-open.

The solution: challenge-response

Challenge-response tokens are the solution to these problems.

Equipped with PIN pads and smartcard readers, to generate the dynamic password for the customer, these tokens use a combination of information sent via the back-end system and information securely stored on the smartcard.

This type of mechanism would work as follows in a PC environment:

A bank customer would log on to the Internet banking site using his or her secret but static password. On receipt of this password, and now having identified the customer, the bank's authentication server would respond via the Internet with a prompt, or 'challenge'. The customer would insert his or her smartcard into the token and then key in this challenge.

The token, equipped with the data from the back-end, the secure and unique information from the smartcard and specific cryptographic technology, would generate a response for the customer which would be displayed on the screen of the token. This response could only come from that specific customer device and could only be based on the use of that specific, bank-issued smartcard.

The customer would then enter this encoded response via the website and it would be transmitted over the Internet to the bank's authentication server. On receipt of the message, the banking server would find the customer's record in its database, encrypt the same challenge using the shared secret key and compare the result with what the customer has sent it. If they match, the user has been authenticated.

The challenge-response model is not open to replay as each challenge and resultant response is used only once. Also, given that this model requires the use of a bank-issued smartcard which is very difficult to clone and which only works in the device together with a specific secret PIN, a second level of security, what you have, is introduced into the authentication system.

Currently, the negatives associated with the challenge-response type model relate to the costs incurred by the banks in making the tokens available as well as the fact that consumers have to be equipped with chip cards in order to use the system. The former issue should be naturally addressed as more vendors release products into the market and start competing on price.

With the South African EMV (EuroPay, MasterCard, Visa) January 2005 deadline fast approaching, wide-scale rollout of chip cards to consumers should also become less of an obstacle.

Gerhard Claassen, Prism Holdings

Share this article:

Further reading: