I tend to agree that the email solution proposed is flawed (from a security
perspective) and introduces a sizable number of usability issues for the
*typical* customer. The system is way too complex and prone to failure for
most non-technical users. Similarly, in a high-tech environment (or high
value transaction site) to would be more economic to go down the physical
token route (esp. once you consider Helpdesk support for an email based
system with a large customer base).
However, an interesting email crossed my path related to this - and again
flawed in a number of ways (not least that less that 1/3 of UK bank account
holders actually possess a mobile phone). I was interested in the structure
of the SMS based system and the costs being directed to their customers --
see below.
BTW - some other options for handling phishing attacks are covered in a
recent paper of mine: http://www.technicalinfo.net/papers/Phishing.html
... On to the copy/paste (hopefully not caught up in too many anti-spam
filters)...
What is Netcode?
Netcode is a second type of user authentication which uses a computer
generated password that is sent to your mobile phone. Mobile is the first
step in a range of options ASB Bank is developing using second type
authentication. It is designed to help us ensure that it is really you
making the transaction.
<http://www.asbbank.u1.co.nz/images/5755/netcode_email_diagram.gif>
Why are we introducing Netcode?
Online security for our customers and the bank requires constant development
as both the number of customers using Fastnet Classic and the number of
transactions conducted daily, grows significantly. A critical part of
Internet security is authenticating your identity when requesting certain
payments online (that is - making sure it's really you!).
When will I need a Netcode to complete a transaction?
You will be asked to enter a Netcode in Fastnet Classic for certain types of
transactions that have a combined value in a day of $2,500 (the transaction
types impacted are listed below). There is a fee of $0.25 per Netcode to
cover transaction and texting costs. Netcodes remain valid for an entire
user session, so once you've received your Netcode it can cover multiple
transactions until you sign off from Fastnet Classic, or your session times
out through inactivity.
The table below shows which types of payments require a Netcode.
Payment Transaction type
- where combined daily value exceeds $2,500 Netcode required
FastCheque Yes
Automatic Payment - set up in Fastnet Classic Yes
Bill Payment where payee entered by customer Yes
Automatic Payment - set up at ASB Bank branch No
Bill Payment to pre-registered payee (i.e. power company) No
Transfer from one account to another in Fastnet Classic No
IRD Payment in Fastnet Classic No
What do I need to do?
From 6 December 2004, ASB Bank customers who wish to use Fastnet Classic to
set up or make payments to anyone other than the pre-registered payees in
Fastnet Classic, where the combined daily value will exceed $2,500 will need
to register for Netcode.
How to register
You can register for Netcode for free by phoning the ASB Bank Contact
Centre, 7 days a week, on 0800 FASTNET - option 2 (0800 327 863 toll free
within New Zealand, +64 9 306 3000 if calling from overseas), or by calling
your relationship manager.
Note: you will be asked to confirm your identity, but an ASB Bank staff
member will never ask you for your Fastnet Classic password or Cashflow PIN
number.
For more information about Netcode visit our web site at
www.asbbank.co.nz/netcode or call 0800 FASTNET - option 2.
Cheers,
Gunter
-----Original Message-----
From: Mark Burnett [mailto:mb@xato.net]
Sent: 29 November 2004 16:15
To: webappsec@securityfocus.com
Subject: Re: Article - A solution to phishing
I have been watching this thread with great interest and
although the basic concept that Michael describes is
interesting and might help reduce phishing, as others have
pointed out it is still vulnerable to a number of other
threats and heavily depends on a number of assumptions that
might not be realistic.
Nevertheless, the fundamental issue with phishing is not that
an attacker can obtain your credentials, but that an attacker
can trick a user into entering credentials in a fake web
form. This is because it is easy to create a fake web site
that looks exactly like the original and it is easy to direct
the user to that site using deceptive links in e-mails,
browser vulnerabilities, DNS spoofing or poisoning, ARP
spoofing, stealth proxies, cross-site scripting, HOSTS file
modification, bookmark modification, trojans, social
engineering, etc.
Protecting authentication credentials is also a problem, but
the solution to phishing is more one of authenticating the
site rather than authenticating the user. First solving the
issue of authenticating the site makes it easier to solve the
problem of authenticating the user.
Mark Burnett
------------------------------------------------------------------
Hacking the Code: ASP.NET Web Application Security
http://www.hackingthecode.com
