A Security Review of the ASB Bank Netcode Authentication System

Saturday, September 18, 2004 (see bottom of page for recent updates)

A while ago, ASB Bank invited me as a customer to try their new Netcode authentication system. As an IT security professional, I was keen to investigate this method of authentication for online banking. Now, before we get started, I'll make it clear that I don't work for ASB, I don't know anyone who does, and they're not paying me for this : they don't even know I'm reviewing their system. As far as the bank is concerned I'm just another customer - although, one that is quite familiar with security systems.

If you use any online banking system, please read this page. Print it off and read it in the bath if you like. Don't worry if you don't understand some technical areas, but there are some very real risks that you should understand which I've tried to explain in plain language.

I'll refer to the bank as simply ASB from here on. Their full name is a little longer.

The Problem to Solve

Online banking is becoming more and more common. Its inevitable that banks want to provide more service to their customers for less cost, and online systems can achieve this. The ASB FastNet Classic online banking system is well advanced in this area. An account owner can not only transfer money between their own accounts, but also instantly send money to other accounts ( commonly called "direct deposit", or E-cheques ). You can also withdraw amounts from your credit-card and put it into your cheque account, or transfer this credit money to another person's account.

Of course, its clear that such a system requires a high level of security, as anyone who can access an account through the online system will be able to transfer money to themselves, withdraw it, and disappear. High levels of security often result in a system which is difficult to use. Its a trade-off situation, and both the bank and its customers need to decide just how much security they are willing to put up with to achieve a sufficient level of confidence that the system is secure while still being easy to use.

What is Authentication?

Authentication is simply the process of proving that a person is who they say they are. There are 3 means to accomplishing this :
  • Something you know. This covers things like passwords, mother's maiden name, the name of one's pets, and so on. Banks commonly use these when you call them over the phone and need to prove you are who you say you are.
  • Something you have. Things like keys, access cards, etc.
  • Something you are. The shape of your face, the tone of your voice, your fingerprints, the geometry of you hand. These are called biometric authenticators.
All of these can be used to help prove you are who you say you are. In most systems, we use single-factor authentication where only one piece of the options available can be used as sufficient proof. Two-factor authentication uses two separate items from different classes, for example a password and a fingerprint would be a very good way of demonstrating who you are.

Online banking systems commonly rely upon passwords alone, or single-factor authentication. Even though the data being passed between your computer and that of the bank is sufficiently encrypted, new kinds of attacks have developed over the last few years that mean this method is no longer sufficient. Many banks around the world are beginning to deploy two-factor authentication because of the risks involved, and the ASB Netcode system is an example of two-factor authentication. It uses both a secret password that only the account holder knows, as well as the person's cellphone ( something they have ).

How Big is the Risk, Really?

There is an increasing number of ways an attacker can get access to a person's online banking username and password ( and therefore gain the ability to pillage their account):
  • Intercepting the network traffic between the user's computer and the bank. This is rare, as any self-respecting secure site will use SSL encryption on their web server to prevent this.
  • Applying duress to the person, for example threatening them with violence or death in order to get them to give out their details.
  • By recording the keystrokes the user makes on their computer. Keystroke recorders can easily be installed if an attacker has physical access to the computer, and also can be installed remotely through various methods such as the trojan horse, or other malware attacks.
  • Through various "social engineering" methods, such as calling the user and pretending to be a representative from their bank and requesting their username and password for various creative reasons.
  • Through "phishing" attacks ( also called a "Joe job" ). Sending the user an EMail message which asks them to click on a website link which is a emulation of the legitimate site. If the user types their username and password into the bogus site the attacker can quickly capture it.
  • Through injecting software into the user's computer to capture information sent to various web sites. There have been reports of malicious software which can be installed into Microsoft's Internet Explorer browser to perform just this.
  • Through attacking the bank's systems and extracting username and passwords from their computers. I would hope that these attacks are rare.

More attacks are being invented all of the time. The above list is just some of the common ones that I know of, there are undoubtedly more, and the people behind these attacks are extremely intelligent and determined.

Now let's look at evaluating risk. There's lots of fancy ways that security experts calculate risk, but I won't bother with them here. Let's say you lose your credit card ( or someone grabbed the number in some way ). As long as you report it promptly to the bank, then you will pay on ly the first $50 of any illicit transactions against your card.

Risk of losing credit card : $50

Its a little harder judging the risk of someone else gaining access to your online banking account. There are no vendors and merchants involved as with credit cards, and there is much less of a paper-trail of evidence. From researching ASB's Terms and Conditions for their consumer-level online banking system ( Fastnet Classic ) they do offer a $50 indemnity amount just the same as with credit cards. However, there are clauses which state that if the user has been negligent in maintaining security then they won't be covered. This is interesting, and quite scary : if you are not technically minded and diligent about your security then you could be at serious risk here. I also wonder just how they would judge what is negligence when it comes to such things. I suspect that the bank would judge each case on its own merits and apply rather objective judgements.

Risk of losing online banking username & password : between $50 and your account balance (plus the amount which can be transferred from the associated credit card or other credit account)

Put bluntly, if you are not diligent about your online security, you could lose everything - plus all the credit you have available.

Responsibility for Authentication

Lets get one thing straight right up front. It is the bank's responsibility to authenticate the person performing transactions. They must prove that you are the owner of the account before you can withdraw money. They will ask for solid identification if you show up in front of a teller with a request to withdraw money, being online should be no different. Unfortunately, its much harder to prove that the person on the far end of a computer connection is really who you think they are. Two-factor authentication is really necessary here.

The Invitation Email

A few things irked me about the Email invitation to join the trial for Netcode. Firstly, ASB has had the policy where it will not send you Email requesting your details ( or requesting you log into their site ), and yet here is one requesting you to go to their site and (implied) to log in. The link to the site wasn't a clickable link ( it was just in plain text to be copied and pasted ), however it was a small breach of what seemed to be a good policy.

Going through the source code of the Email there was definitely some issues here. There was no evidence that the Email had come from ASB bank at all. It seems to have been sent by some organisation called "unitymail.co.nz" whose mail server IP address resolves to 210-54-252-19.ipnets.xtra.co.nz in DNS ( xtra.co.nz is a major ISP in NZ ). I suspect they were probably contracted by the bank to send the EMail, however anyone could have sent this EMail: it did not come from the bank.

Within the Email message there is lots of HTML formatting. In itself this isn't a big worry, but in this message there are embedded images which are fetched from a website "http://www.asbbank.u1.co.nz/". Now u1.co.nz belongs to MessageMedia NZ Ltd, not ASB Bank, which is again quite suspicious. The fact that the images are links means that the people at u1.co.nz will be able to look at the log files on their web server and see how many people loaded those images and where those people are on the Internet. This is a common tactic used by marketing people to evaluate how much penetration their Email message is getting : however I view it as a privacy abuse.

So here we have an EMail message coming from two companies, and not from the bank at all. It resembles the "phishing" attacks that are often sent as a ploy to capture people's online account details. This is a very bad way for a bank to contact customers.

Registration

Registration for the service is relatively painless. The web page referred to by the invitation Email simply give some details and refers to use to contact an operator via phone. I think they could have done a registration page within the online banking system itself, this would be more likely to get more early adopters for the trial.

The operator asked a few of the usual security check questions, then took my mobile phone number and registered it against my account for the Netcode service. I registered 4 days after receiving the Email invitation, and the operator admitted she hadn't performed a registration yet, so I suspect uptake for the trial system has been slow.

Using the Netcode Authentication System

To use the system, you need to contact a service representative, and give them your cellphone number. Once this is completed then you're ready to go. When you make transfers within the online banking system, the system will send you an 8-digit number to your cellphone via the SMS service. This is then entered back into a form on the website and, if all goes well, your transfer will be approved and go ahead.

During my testing, I had to make a transfer of $2,500 or more ( I performed a transfer of $3,000 for testing ). Response time to receive the Netcode number was very quick : within 10 seconds my phone beeped with the message:

netCODE: 07212772 (Message#: 36162206) Contact your online helpdesk if you have any questions.

You'll need to be fairly prompt in entering the Netcode number. During my test transfer someone came up to me and started talking, delaying me by about 3 minutes. In this time the Netcode number had expired, and the system promptly resent a completely new code.

It was very easy to use, the layout of the fields on the banking site were easy to read and understand : 10 points for useability for the bank here.

Instructions on what to do in various situations ( such as when you don't receive the Netcode SMS message, or if you receive one and didn't perform any transaction ) are in a FAQ page on ASB's Netcode site. In most cases the advice is to call the customer service centre.

To change you cellphone number you need to ring the customer service people again. Obviously, there is no way to do this online ( an attacker could change it to his number and foil the whole system ). This would have to be done quite promptly if you were to lose your phone, if only to be able to make transfers again. I didn't see any instructions indicating what I should do in such a case.

The Sytem Being Used

The system used seems to be an adaptation of the RSA Mobile authentication system. It works by creating a random nonce which is attached to the transaction being requested. A nonce is a number-used-once, a throw-away number which in itself has no meaning or use after it has been entered back into the system to authorise the transaction. This method of authenticating the user through something they have and explicitly authorising the transaction is quite secure.


Interestingly, RSA Asia-Pacific admits that there are problems with this system ( see story here ) which are :
  • The cost of sending SMS message to the phone. In New Zealand the "retail" cost is NZ$0.20 per message ( about US$0.13 ). Its not much, but if applied to every transaction it would quickly add up and users would not be happy paying this on small transactions.
  • Coverage. If you're outside cellphone coverage then you can't do online banking.
But there are other issues as well as these. Some that I'm aware of are:
  • Reliability. The SMS service is usually prompt and reliable, but sometimes it isn't. I've personally seen delays of a few hours in sending messages between handsets within the same city. Sending messages overseas is often worse.
  • Not everyone has a cellphone.
Given these issues, ASB will be using the system in a limited scope. Only large transactions ( those greater then $2500 for the trial ) which transfer money out of the user's account will employ the system, and it will be gradually trialled to a limited number of users before it is made widely available. A safe move by the bank here, although it is still possible for an attacker with the user's login and password to extract smaller amounts of money. I believe there is also a daily limit of the amount that can be transferred before a Netcode authentication is forced.

Its also worth noting that the system has been designed so that you only need to perform the Netcode authentication process once per online banking session. If you first make a transfer of more than $2500, it will send the code to your mobile. If you then perform another transaction it will remember that you've recently performed the authentication and suppress a repeat. If you log-off or exceed the online banking timeout ( about 10 mins ), this cached authentication state will be cleared.

ASB Security Posture in General

In reviewing the details of the Netcode system, I looked over ASB's online security statements. These were found to be rather lacking. They say that their services are secure on the basis that they use 128-bit encryption, and there is no mention of any other security mechanisms in place. This is clearly not sufficient. Well-known security expert Bruce Schneier often uses the analogy that using a cryptographic solution to a security problem is like protecting your property by placing a pole in the ground with the intention that any intruder will be stopped when they walk into the pole. There is much more to securing online banking systems than the 128-bit SSL key used by the website and ASB should give further assurances that such systems are in place.

Conclusions and Comments

The Netcode authentication system solves some of the problems outlined in the risks section above and it goes a long way to mitigating the risks of online banking.

While the Netcode system will improve security for those people who use it, I believe that very few customers will subscribe to the service. Apart from the problems listed above, uptake won't be widespread for two reasons

  • Those people who are security conscious won't need it as they will have reasonable measures in place. They will have installed the latest patches, virus scanners, and firewalls on their computers. They will know the risks of losing their bank login name and password, and will be taking precautions.

  • Those people who aren't security conscious won't subscribe either because they will believe that they don't need it, believe that the bank will cover them, or simply believe that it isn't worth the cost.
Yes, there is a certain amount of irony here, and I'm also aware that it is very much a security-centric point of view.

The first group can demonstrate that they have not been negligent in securing their access to the online banking system and will therefore come under the $50 indemnity clause in the online banking Terms and Conditions. While the second group of security-agnostic people could arguably be found to be negligent if they were to disclose their login details through some means and not be able to claim under the $50 indemnity clause. Clearly, it is this second group of people that are not security conscious that really need this system, and for that reason the marketing people at ASB will have a hard time convincing people to use the Netcode service.

Disclaimers

Some names contained in this document ( Netcode, Fastnet, Fastnet Classic, etc. ) are be trademarked and owned by their respective owners ( ASB Bank ).

The comments presented are the opinions of the author.

References

Updates


Update : 8 November, 2004

ASB Bank issues a press release on NetCode. The system will be mandatory for all customers performing transfers of $2500 or more, and will cost 25cents per SMS-authentication. Note that the authentication will be cached per login session. The article mentions that the user will be able to set the $ amount at which authentication is required, but details are sketchy at this stage. Story at Stuff.co.nz

Update : 26 November, 2004

ASB Bank sends an Email to customers. Relevant points of note :
  • Trial ends 5th December, 2004
  • As of Dec 6th, all personal banking customers are required to use Netcode for transfers of NZ$2,500 or more
  • Each authentication session will cost NZ$0.25 to cover cost of text message, etc.
  • ASB Bank is the first bank in NZ to use two-factor authentication for online banking. ( Although note that this only applies to some transactions ).
The Email ends with the footer :
This email was delivered to you by MessageMedia (NZ) LTD on behalf of ASB Bank. Call ASB Bank on 0800 FASTNET (327 863) for verification if required.
- which still could have been written by anyone, but at least you can phone someone at the Bank and verify the Email message. Maybe.

Update : 14 December 2004

The policy for transactions requiring Netcode authentication have changed a little : no Netcode authentication is required when the destination account has been "loaded" by bank staff.

Update : 18 January, 2005

Local Internet commentator Bruce Simpson has commented about such 2-factor authentication systems. He mentions well-known vulnerabilities with respect to key logging and man-in-the-middle attacks ( MITM ). When I initially looked at Netcode, I realised that such attacks were possible and notified the appropriate people at ASB Bank and discussed possible fixes. These MITM attacks are possible, but not currently practical, and it would be easy for the bank to detect such an attack by closely monitoring for erratic traffic through their web servers.

Update : 5 April, 2005

MIS Magazine have written up a nice overview of banking authentication here, which quotes information from this page and includes a good description of the risks involved.

Update : 10 November, 2005

A number of changes over the last month or so:
  • The threshold for Netcode authentication was reduced to $800
  • Users have the option to reduce the threshold through the online system
  • A new system has been deployed using RSA SecurID tokens for authentication (key fobs with a rolling 6-digit code). Customers can choose to use the new tokens if they want to (not compulsory), cost is a very reasonable $1/month. I have not reviewed this system in detail (yet).