RE: Article - A solution to phishing

["WebAppSecurity [Technicalinfo.net]" <webappsec () technicalinfo net>]

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