Security solutions for e-banking and e-commerce with credit/debit cards,- Part 1: Analyzing the Security IssuesOmar A. Herrera Reyna â€“ CISA, CISSP
With all sort of attacks against e-banking and e-commerce systems targeting primarily customers, securing transactions has become increasingly difficult for banks and online stores.
See Also: LIVE Webinar | Stop, Drop (a Table) & Roll: An SQL Highlight Discussion
There is a widespread use of credit and debit cards for shopping online. However, there use for e-banking (e.g. payments, money transfers, etcetera) is very limited. This is probably because we still tend to view them only as payment tools.
Concern about stolen and misused credit card information is rising. Also, banks and companies have been severely affected by fraud involving credit and debit cards. A good example of this is the security breach at Cardsystems Solutions Inc. earlier this year.
Adequately protecting credit card information is not only essential to guarantee secure e-commerce, but it also offers the possibility of extending the uses and services of cards, especially for e-banking purposes.
Root of the problem
Before we start reviewing some of the current solutions, it is worth checking what the root of the security problem with credit/debit cards is, and what mistakes have we made in the past.
First, credit and debit cards were originally conceived as a replacement of cash for physical payment operations. In this context, limited identification and authentication controls in the past (i.e. magnetic band and autograph signature) appeared to be sufficient. But card fraud quickly showed that card security controls were not strong enough.
And so we have found the root of the problem:
â€œSo far, we have attempted to use authorization and authentication information that is easily retrieved from credit/debit cards, either because it is printed or stored in an insecure medium (i.e. magnetic band)â€
Yet, we ignored this situation and attempted to expand the use of the credit card, allowing phone purchases and internet payments soon after there conception. This did not allow us to use the limited security offered by controls in the traditional cards (i.e. autograph signature and magnetic bands), because we simply couldnâ€™t. These controls were not designed for remote authentication and identification. So another mistake was made when we used printed information for authenticating and identifying the user.
This leads us to our first security law governing online financial transactions:
â€œFor any online financial transaction tool, as long as the required elements of authentication and identification for a payment are physically and easily accessible to anyone, this tool is not secure for online paymentsâ€
Thatâ€™s why we donâ€™t use traditional cheques for e-commerce right? Well, give it a second thought. You could easily print all security numbers on a cheque and ask for some information on the account holder, just as we do now with credit/debit cards for online payments. Now try to go a little bit farther, instead of serialized numbers, print a random, unique, cheque number on the cheques. Cheques are only used once, and credit cards are not, so which is the most secure payment method now?
Now Iâ€™ve been a little unfair with the card industry because smart cards have been available for some time, and they work very well (if correctly implemented). Fore example, Chip and Pin technology recently introduced these cards in Â France and the United Kingdom. These cards have show a reduction of 80% in overall card fraud.
So thatâ€™s great for physical payments with chip cards, but unfortunately, we need more that just a chip card in our hands to be able to do safer payments online.
Analysis of current solutions
There have been numerous attempts to reduce the security risks of online payments so far. Unfortunately, many attempts have been more reactive than proactive, as they do not take into account the root of the problem. Therefore, some might offer a base for using credit/debit cards as unique physical and remote tools for all our payment needs (i.e. not only e-commerce but also e-banking), however, our security practices in this regard are not mature enough to handle these transaction.
1. Accept the risk
The first solution that we can think of is, doing nothing and simply accepting the risks. That is a solution that many are seriously considering, given the cost of implementing other, more complex solutions.
For example, American Express decided to do this. They simply offer fraud protection for their customers, so that none of them will have to pay anything if they become victims of fraud.
Thatâ€™s a simple solution with benefits for both customers and the credit card company, but Iâ€™m thinking about what the most paranoid customers (like me) might think about this. Seriously, I just fill my claim and get my money back? What will I need to demonstrate to ensure that I did not make any illegal purchases? How much annoying paperwork is this going to require? Therefore, it might not be that easy to convince all customers to accept this solution. Additionally, while it is a viable solution, this solution is reactive in nature and will not protect against problems in the future.
Note that in this particular case, American Express also decided to remove the smart chip included in some Blue cards. This was not specifically related to security but to the speed of physical payments. American Express decided to replace the chips with a proximity technology called ExpressPayâ„¢. However, by removing the chip they also rendered useless their ID KeeperÂ® software, which allowed users to store user names and passwords in the chip. Even if this process wasnâ€™t directly implemented in regard to payment security, this security tool could have been useful to enhance clients overall web browsing security.
For an institution with very low fraud rates involving credit/debit cards, this reactive plan may be the way to go, however, this will only work if the low fraud rates stay constant.
2. Secure channels
I consider this solution to be more of a patch than a real attempt to stop credit/card fraud considering the current implementations with SSL/TLS and on-line shopping and banking.
There is nothing wrong with SSL, TLS, VPN and all secure channel solutions; they work well but are simply not enough of a security solution to limit credit/card fraud.
Phishing, spyware, trojan horses and other sophisticated targeted attacks made many customers realize that SSL is not a panacea. The problem with SSL is that they are not real point to point solutions in terms of the security required to do secure financial transactions.
They only cover the communications channel between the customerâ€™s computer and e-banking/e-commerce servers. They do not provide security for information that is being processed or stored (i.e. name, address, credit card numbers), and they donâ€™t reach the credit/debit card at the other point. Â That is why phishing and spyware attacks are able to circumvent security provided by these channels.
Simply put, spyware installed at the customerâ€™s computer by social engineering can easily capture and transfer credit/debit card information without having to deal with the cryptographic issues of secure channels. On the other hand, hackers can also steel the information from servers where it exists in clear text format. Circumventing these security controls can occur almost as easily (remember the Cardsystems case)
This is what I call the last inch security issue, because we are so close to providing complete security coverage but at the same time so far of really achieving the goal. This leads us to our second security law governing online financial transactions:
â€œFor any online financial transaction tool, any security solution not covering the transactions point to point, from the transaction tool itself up to the system that will process the transaction, provides only partial securityâ€
Another drawback of this approach is that each e-banking/e-commerce web site needs to install the security solution properly. Installations can have different configurations that offer varying degrees of security.
Consequently, people should avoid telling customers that e-banking/e-commerce sites that transactions are 100% secure just because those sites happen to have a digital certificate and use some kind of secure channel technology such as SSL or TLS, to secure the connection. Â While having these secure connections will not protect a user from all fraud, having these secure connections are much better than having nothing.
3. Additional codes and secrets
Another solution is to add some kind of secret to the use of the card. Because we donâ€™t want to only use readily available information on the card (i.e. printed information), it seems pretty obvious that this solution should overcome the some of the security issues outlined before.
Security under this scheme rests then on the secrecy of that additional piece of information, be it a pin, a password or whatever you would like to call it.
Both Visa and Mastercard have implemented security solutions that work in this way, called Verified by Visaâ„¢ and SecureCodeâ„¢ respectively. In this case, the customer may register a password with their card issuer, and they are asked for it during online-purchases. That way, the customer is identified with the customary information (e.g. name, address) and then authenticated with the password.
The advantage with this scheme is that, in general, it can be used for other purposes, such as online banking. If customers use this secret to make purchases, they can use it as well for access control and also to authenticate transactions (e.g. tax payments or fund transfers) that involve the use of their card. Another advantage is that it is very easy to use for the customer and it does not require any technical expertise.
A disadvantage is that online stores need to install a piece of software on their web pages to enable the use of this feature. Therefore, this requires some investment by the stores and the card issuers, and it might not be available at every site on the Internet.
Yet, a password is a password, with all its advantages and disadvantages from a security point of view, and this scheme suffers the same vulnerabilities as any password scheme.
Also, security coverage is not complete from a financial transaction point of view (our second security law governing online financial transaction tools comes to mind), and this scheme is still vulnerable against attacks conducted by spyware, or phishing.
4. Random or changing information
This is also a popular solution implemented by several banks, mainly for controlling access to e-banking systems. For example, BBVA in Spain and BBVA-Bancomer in Mexico give customers a code card which inserts additional information. Customers provide their password along with some extra information extracted from these cards that is specified by the e-banking website. The solution is not new, and resembles authentication methods implemented by some banks several years ago to authenticate users that used banking by phone.
The result is that users provide different authentication information each time. So the idea sounds good to do authentication point to point of the user, but unfortunately the implementation is far from perfect. There is a fixed number of authentication information that can be appended to the user password which means that someone that managed to compromise customerâ€™s computers might just need to wait a little bit longer to get all (or sufficient) information to access the e-banking site illegally.
So you might have already guessed what our third security law governing online financial transactions might look like:
â€œFor any online system dealing with financial transactions, any security solution not covering customer authentication point to point, from the customer itself up to the system that will process the authentication, provides only partial securityâ€
Some institutions have considered the use of rudimentary one-time-pads, which means that the changing information is used only once. But this implies that these pads need to be physically delivered to the user, frequently and securely.
Regardless, any card solution of this type, be it a reusable or one-time-pad with additional access information, has the information printed on it, so that if they are lost or stolen, the game is over. Another small disadvantage is that the users have to carry this card with them to be able to access their e-banking information.
But for the cost of implementation and the ease of use, the additional security provided by this kind of scheme might be worth considering.
On the e-commerce side of the coin, there are already solutions similar to our randomly serialized cheques suggested at the beginning of this article, and this is how they work:
The card issuer generates a disposable credit card number that might only be used for a single transaction, the customer makes the transaction using that number and, if someone steals the information they canâ€™t use it again for fraud. Some examples of companies who have offered this kind of protection include American Express, MBNA and Discover. It offers customers a secure method to complete online payments, and it does not require online stores to get involved or make additional investments.
There are a few disadvantages of course. Like the one-time-pad, there must be a way to deliver or securely generate these unique credit card numbers. Also, with some purchases (e.g. flying tickets confirmations or validating a warranty), the customer might be required at some point to produce the credit card with which he made the payment, which of course does not exist.Other than that, this scheme provides an excellent amount of security for online transactions.