| secure e-banking, online banking requires transaction authentication, rather than user authentication |
| Two-factor authentication won’t stop identity theft, because identity theft is not an authentication problem. Unfortunately, it is a transaction-security problem. Solutions need to address the transactions directly |
| We tell you, how you can find out quick and easy. |
We have addressed this issue previously here:
- What have HSBC, UBS and the Bank of England and others in common? Insecure online banking services
This is how the website’s frontpage looked like this morning in DK:
x
If you cannot view the above image see here:e-banking in DK is not always safe it seems
Get the article as pdf file here: Sharp kritik af danks netbank-sikkerhed
or else just visit the Website Version2.dk – Sharp kritik of danks netbank-sikkerhed
============>
Jesper Laisen wrote a nice response to the Danish article here (in Danish)
GOING DOWN MEMORY LANE
A few years back, of course, we all got a list of transaction authentication numbers (TANs), each to be used only once. For online banking, the client had to authenticate herself with the username/password combination. Most importantly, one had to provide the next transaction number from the printed list.
No malicious software could get into the drawer of one’s desk to get the list. Even secretly making a photocopy of the list was of limited use, because the user would notice it at typing in the next transaction number. Online spoofing the TAN, or man-in-the-middle attacks could allow a malicious person to change one single transaction, but it would be immediately apparent to the legitimate user. The latter would discover that her own transaction failed or ddid not not produce the expected account balance. A telephone call would prevent any damage.
HOW IT COULD WORK TODAY
Early in September 2007, California’s Bank of America (BofA) was debuting an added security feature for its online banking customers. The optional service, called SafePass, sends a six digit code to customers’ mobile phones that can be used to authenticate banking transactions. The code can be used once and is valid for 10 minutes. BofA customers can choose to require SafePass authentication for various types of transactions. While this is interesting, it assumes that mobile networks are closed systems and safe.
The technique as applied by Bank of America makes the dangerous assumption that the cellular network is closed, well-controlled, and in particular envelops both the originator of the message (e.g., the bank) and the user’s cell phone. But three technological trends in the telecoms industry mean this assumption no longer holds true:
1) The cellular industry is moving away from the use of proprietary network-level protocols for the delivery of services such as SMS. For example, the newer Multimedia Messaging Service (MMS) is based on open Internet protocols such as HTTP. The knowledge needed for the creation and spoofing of messages is therefore becoming much more widespread.
2) The closed and secure networks offered by the telcos are being opened up and interconnected with the public Internet to offer the “wireless web” experience as well as third-party messaging services. Therefore, these networks no longer represent a completely separate and independent channel to the Internet. The origination of messages is becoming easier as it no longer requires a specialized and dedicated network connection to the telco.
3) Older handsets where the software is completely controlled by the manufacturer and network operator are being replaced with smart devices that are fully programmable by the end user.
There are now many possibilities for malware and man-in-the-middle attacks from rogue applications running on the mobile phone itself. For example, with smartphones using the Symbian operating system (and to a lesser extent Java/J2ME) it is possible for applications to intercept all incoming SMS messages as well as have full control over the user interface.
As a result, it is simultaneously becoming easier to inject false messages into the two-channel authentication mechanism as used by Bank of America, as well as to intercept valid ones. Unfortunately, our experience is that not all IT experts and telecom enginers seem to fully appreciate these developments.
As well, two-factor authentication won’t stop identity theft, because identity theft is not an authentication problem. Unfortunately, it is a transaction-security problem. Solutions need to address the transactions directly as the example in the Table below illustrates.
| One of CyTRAP Labs’ customers implemented the following transaction authentication system |
|
| 1 | bank customers are issued an ATM card that has a chip holding their PIN |
| 2 | e-banking customers have a challenge-response calculator (a token).Every calculator is unlocked by inserting the ATM card AND entering the PIN.Once the PIN is entered, the calculator is ‘personalized’ for use by this particular customerOnce the ATM card is being removed or after a few minutes of having been inserted, the calculator will go to sleep. This requires that the PIN is being re-entered to wake up the calculator/token. |
| 3 | users wanting to login to the bank’s internet website must provide their bank account number AND the serial number of their ATM card. Naturally, the latter is not the same as the PIN.If the above is correct, then the client is shown a challenge (contains eight digits) that she must enter into the calculator.Once the challenge is entered, the calculator responds with the computed 6-digit response. |
| 4 | At this point the user has access to the account; he can prepare but not send payments.Typically the user pays accounts that are in his bank address book (e.g., regular payments for which details have been stored on a sort of template).Each new account entry to the address book generates a challenge-response from the bank (and that probably also means the user has to re-enter her PIN to wake up the calculator as well). If a user makes a large payment to an account that is not part of the address book, then there is also a challenge-response required to validate the receiving account details. |
| 5 | Once the client has finished entering payment details and all payment orders have been queued, the user selects “Send to bank”. A list of all the queued transactions (payees and amount to be paid) is displayed and a final challenge-response is required before the batch of payments is being entered into the next day processing queue. |
x
The above system is not perfect. Nonetheless, it makes a so-called man-in-the-middle attack really difficult, since the client has to authorize the transaction that she was not the originator of. While there is some extra work for the user, in return she can have more confidence in the online banking service.Naturally, there are better systems than the one described in the Table above.
Nonetheless, it is a bit less convenient for sure but the challenge-response in case of payment to a new account not ever used before helps reduce the risk of having a cybercrime fellow sends his regards lateron.
The above described system authenticates the transaction. This is vital since the individual authorizing the transaction could be a hacker.
CONCLUSION or CyTRAP Labs’ take on this issue
However we approach this security issue it all boils down to money. Denmark had 70 or so cases during 2007, where these customers’ digital signature may have been stolen or used to get funds illegally. This caused the banks to absorb about Euro 450,000 in losses. Does this justify changing the system to a more expensive and secure one for the banks affected?
Looking at this issue from the banks’ perspective we suggest YES.
For instance, our work has shown that there is a direct link between the level of trust customers have in their bank, the loyalty they give the bank and, as importantly, the extent of use of the bank’s online services.
Even among clients that have a high trust in their bank, about 60% have indicated if asked/surveyed they would stop using that institution in the event of a single privacy breach or data security breach.
Hence, negative publicity about these 70 Danish cases may result in many more customers changing banks and/or refraining from doing Internet banking. A much more expensive proposition than the 450,000 or so in fraudulant transactions that the banks had to absorb last year.
Hence, if competitive markets work as they should, better security for online banking will have a positive effect upon bank’s bottom line. Hence, customers should demand satisfactory security levels for online banking. If they do, Danish financial institutions will most certainly respond to this pressure accordingly and offer better security …. that is how the market works
PS. Of course some Danish financial institutions offer a high-level of security to their online customers already now.
==========>
Alerts, zero-day exploits advisories, risk tools, regulatory intell and SEO marketing from CyTRAP Labs are trusted by the experts.
For instance, FiRST’s CERT members receive much of this material via the FiRST news and threat alert service.
Why not become one of our readers by subscribing right now to one or more of our highly acclaimed services?
==========>
Find more infos about this topic here:
Press Release – Urs+Nahum’s Security Checklist
Regulation that matters? Online banking services – survey says: antifraud measures insecure
====>
Urs this is now also in the ErhvervsBladet.dk
Hård kritik af sikkerhed i netbankerne – Eksperter kritiserer bankerne for at spare på sikkerheden
http://www.erhvervsbladet.dk/article/20080104/news04/80104029/
Incidentally, I like the Bank of America example in your story
http://blog.cytrap.eu/?p=322
As you youtline nicely, the SMS challenge is not necessarily a trustworthy authentication scheme for bank transactions…. considering that mobile ecosystem is ever more opening itself to re-sellers (e.g., Virgin) and the Internet in general.
Unfortunately, many people forget this important development when suggesting we use SMS to send customers their code to authorize a particular transaction
Nice job.
Jakob