Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Article - A solution to phishing |
|---|---|
| Date: | Tue, 30 Nov 2004 08:54:50 +1100 |
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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Fwd: PHP Easter Eggs, Alexander Klimov |
|---|---|
| Next by Date: | RE: Article - A solution to phishing, Michael Silk |
| Previous by Thread: | RE: Article - A solution to phishing, WebAppSecurity [Technicalinfo.net] |
| Next by Thread: | RE: Article - A solution to phishing, Michael Silk |
| Indexes: | [Date] [Thread] [Top] [All Lists] |