RE: Article - A solution to phishing

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

OK,

It's all a matter of perspective - just like the classic Irish saying
"theres a cork for every bottle" (or did I get that wrong and it's really
just what mothers tell their ugly daughters?).

Anyhow, a web-based authentication system that relies on email as part of
the second factor validation process will suffer from the following problems
(please bare in mind that I'm initially focusing on the classic "large bank"
scenario):

1)  Depending up what random stats someone bothers to dig up, the vast
majority of online bank users use webmail-based mail clients (e.g. Hotmail,
AOL, Yahoo, BTInternet, etc.) to read their email.  As has been seen many
times before, these types of popular mail clients are actively targeted and
access to lists of "hacked" accounts are commonly available or traded.    
2)  In way too many cases, webmail customers keep old emails from their
banks (and other "trusted" sources) that will typically provide much of the
information necessary to uniquely target the stolen email users bank
account.  Now the email hijacker can just use the email account to "refresh"
their password, or request the two-factor token?  Not smart.     
3)  There is a notoriuos latency in most popular webbased mail
clients/providers.    
4)  The purpose of a Phishing scam is not just financial fraud - in fact the
more common representation is identiy theft.  Identiy theft frequently
includes the theft of mail access credentials as well.    
5)  Using a similar arbitrary stats generator - I think you will find that a
sizeable proportion of most banks users have no access to webmail (or have
any idea of how to getting it work) if they are familiar with Outlook etc.
(after having carefully followed their ISP's instructions to set it up
several months previously) -- therefore the "portability" of the solution
has to be questioned if the user is _not_ sat down in front of their own
personal PC.    
6)  How many people have linked their online bank account email account to
their work email address??  I would suggest that (again) a sizable
proportion of people have no access to this vital email outside of their
work premises.  Are they too going to be denied access to their bank
accounts from home or Internet Café?    
7)  I have worked with enough sysadmins who have come from ISP's and
internal support teams to know that they like nothing better than sifting
through other peoples email's - normally monitoring email "on the fly"
because that’s the best way to get hot gossip and have fun.  Therefore,
email within a closed business system is not to be relied upon for
private/personal information.  And before anyone starts, if the company is
less than 500 staff, you can pretty much guarantee that the sysadmins also
like watching the firewall/proxy to see which sites people are visiting as
well.    
8)  An authentication system must also be robust to stand against threats
present in Internet Cafes - i.e. keyloggers and backdoors.  So, if someone
has to access their bank account, but must also access their webmail to get
the second factor variable - the keylogger has also captured their email
login credentials.
9)  Out and out complexity.  The fact that people are reading this thread
(in this security forum) instantly means that they are not typical users,
and can probably be counted in the top <insert arbitrary stat here>% of
skilled Internet users.  I think you will find that the vast majority of
ebank users are so focused on making sure they just type in their password
correctly (and not encounter a horifying message telling them that they did
some thing evil and wrong like typing a wrong password) and not locking out
their account, that any diversion (such as opening an email client and
copy/pasting data) just isn’t going to fly.
10)  Your comments about "forgot my password" - I think you will find that
way too many people dread forgetting their password for fear of never
finding it out again - regardless of what their bank tells them.  Users like
their passwords, and will always try to change it to something they like and
can remember.  If a user can't just remember it themselves, it will fail to
be used by much of "joe public".


With regards to man-in-the-middle attacks.  You are correct that there is no
elegant method of protecting against such an attack (although there are
increasingly elegant ways for corporates to monitor their applications for
access via such MITM attack vectors - and respond accordingly) -
consequently you take what protective steps you can against the threats you
can manage.

Like I said at the start, I'm sure there could be some application for the
two factor authentication system you have proposed.  However it is unlikely
to be successful in a commercial ebanking environment.  But, and I must
point this out, Phishing (at this point in time) is something like 75%
targetted at ebanking (see the www.antiphishing.com site)... And the if that
is the threat you are proposing to protect against, then email is not a
useful second factor.  In fact I doubt that SMS is of great value to most
popilar high-street retail banks as it too suffers greatly from latency
issues (it's not uncommon to receive SMS texts several hours late if sent in
peak times in London for instance - or several days late if travelling
internationally)... And buggerme if I'm going to pay for the "privilege" of
paying for an SMS message so I can pay my Visa bill online!



Cheers,

Gunetr
 

> -----Original Message-----
> From: Michael Silk [mailto:michaelsilk () gmail com] 
> Sent: 29 November 2004 21:55
> To: webappsec () technicalinfo net; webappsec () securityfocus com
> Cc: mb () xato net
> Subject: Re: Article - A solution to phishing
>
> 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