Re: Article - A solution to phishing

[Michael Silk <michaelsilk () gmail com>]

Hi,

        The system is complex, but not from a users point of view - not more
complicated then they would otherwise face with a "forgot your
password" system.

        You mention the physical token but, as pointed out, it's susceptible
to MITM attack.

        The critical thing to note about my proposal was that the user can't
_accidently_ use the correct password at the wrong site. Even with a
token you could be tricked into visiting an fake site and plugging it
in, etc.

        I don't see - ignoring problems with email delivery - how this system
would be more complicated for the users.

        I have actually created an email based login-system _to make it
easier_ for the users. (of course, it was internal only).

        What do you (or anyone ...) consider the main flaws in it, that
haven't been addressed ... ?

-- Michael

 

-----Original Message-----
From: WebAppSecurity [Technicalinfo.net] [mailto:webappsec () technicalinfo net] 
Sent: Tuesday, 30 November 2004 7:09 AM
To: webappsec () securityfocus com
Cc: 'Mark Burnett'
Subject: RE: Article - A solution to phishing

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