Card Not Present Fraud

First Person: Protecting Customer Trust in e-Banking

Mexican Banking Executive Offers Tips from Experience with Tokens

During March 2006, Mexican banking authorities established the use of a second factor authentication based on "dynamically generated information" -- in addition to username and password -- as a requirement for doing monetary operations through e-banking systems. This regulation allowed the use of one-time access code generators (e.g. tokens) and random access codes tables.

Most banks with e-banking systems used tokens to comply with the regulation's deadline of March 2007. One year later, the results look promising from the client's security perspective, but there are also lessons to be learned.

Early Bugs
After implementing this measure, Mexican banks with e-banking operations reported virtually no frauds involving traditional phishing schemes. This was a huge success, except for a few cases where some e-banking users were attacked with custom malware that gathered token codes, which then were used to commit frauds.

It was determined that a particular type of tokens that were event-based (i.e. they are synchronized with the central banking system through a seed, but do not depend on time) were easily attacked. The scheme worked more or less like this:

A fake email purportedly from the bank was sent to customers, urging them to download a piece of software to "protect" their token-generated access codes, username and password;
The piece of malware transferred the collected information to the fraudsters;
Since the codes didn't expire, fraudsters could use them as long as they logged to the e-banking system before the victim.

Banking authorities and security departments became aware of the problem and started to take measures to protect clients. Some even were in favor of more strict requirements, such as forbidding event-based tokens and random access code tables, as well as to require two-way authentication tokens. But it was obvious that the problem would still not go away.

For instance, time-based tokens (i.e. those whose access codes are valid only during a certain time frame, ranging from a few seconds to a couple of minutes) are still vulnerable to such types of attacks. They just make it a little harder for fraudsters because they have to work faster. But automating the process by programming the malware in such a way that it can gather the dynamic access code and execute the fraudulent transaction in real-time thwarts the security provided by these devices.

Flaw in the Design
It's not that tokens are vulnerable; they work quite well. But the solution they were required to work in is flawed by design. The basic requirements for a man-in-the-middle attack are still precisely in the most difficult point for banks to protect: the client's computer.

In some countries, authorities are going for mechanisms where the bank would be able to use intrusive controls to somehow assure that the system is trusted (e.g. by checking that updated antivirus, anti-spyware and personal firewalls are installed). However, with the diversity of hardware and software configurations, as well as the decreasing effectiveness of blacklist based controls (i.e. anti-X software), this scheme won't solve the problem. Not to mention the potential costs and legal issues that this approach poses in some countries.

Changing from each token technology to the next, year after year, is prohibitively expensive and brings no clear benefits to customer. What needs to be done is to work harder in the solution's design for a scheme that will provide robust and lasting security for e-banking customers. For example, Mexican banking authorities and banks are already in this process, and while e-banking fraud cases in general have been reduced significantly, we know it is only a matter of time until fraudsters adapt and start applying new techniques to get around the current solution.

We know that we can't make it too hard for the customer to use e-banking systems, but there is no way to directly encode, obfuscate or encrypt the plain access codes produced by tokens, so that banks could be sure that only customers are using them, without asking people to perform some kind of operations with their brains.

The Solution?
Still, there is a way to avoid man-in-the-middle attacks even with clear text dynamic access codes: Combine the generation of access codes with information of the transaction. The resulting code would be generated by a cryptographic operation performed by the token using this information and the seed/time synchronization data shared with the bank. There are already some tokens that are able to do this, but the same can be achieved the same with smart cards plus smart card readers with independent keywords and some soft tokens with independent hardware (e.g. cell phone software token generators). It is important to use independent hardware to get the data and perform the cryptographic operations.

The resulting codes are still clear text, but the fraudsters cannot modify them. If they do, they will at most cause a denial of service for the customer. This scheme works like this:

Customer writes the destination account number in its access code generation device (e.g. token, smartcard, cell phone) and gets an access code;
Customer sends the access code and destination account number to the bank (in clear text);
Bank validates the destination account number for the transaction and authenticates the user at the same time.

Whether the cost of implementing this solution is low enough to make massive deployments right now remains to be seen, but banks and banking authorities worldwide might benefit from this experience and start looking at similar solutions so that e-banking security relies on robust design, rather than on security hardware or software characteristics.

About the Author: Omar Herrera, CISA, CISSP, has a graduate degree in Forensic Computing from Bradford University in the UK, and currently works as Chief Security Officer for BancoFácil in Mexico. He has several years of experience in information security in the financial sector and worked previously for Wal-Mart Bank, the Central Bank of Mexico and Deloitte.


About the Author

Omar A. Herrera Reyna

Omar A. Herrera Reyna

Information Security Officer, Central Bank of Mexico

Omar Herrera is an information security officer working for the central bank of Mexico. He has previously worked as information security consultant for Deloitte and is member of the OISSG. He is experienced in technical information security assessments, risk analyses, incident response team management, technical security training and malicious software analyses.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.co.uk, you agree to our use of cookies.