full-disclosure - Request for comments: anti-phishing storefrontapproach

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0eb401c56944$8e2f3c00$6fd4a8c0@othello>
Date: Sat Jun  4 21:32:56 2005
From: niceman at att.net (Mike N)
Subject: Request for comments: anti-phishing
	storefrontapproach

 On Fri, Jun 03, 2005 at 07:37:28PM -0400, Doug Ross wrote:
> Given the recent PR regarding Bank of America's SiteKey (which seems
> to me to be susceptible to MIM attacks), I'd appreciate any feedback
> on this anti-phishing approach:
>
> http://directorblue.blogspot.com/2005/06/making-phishers-solve-captcha-problem.html

  Checklist item 2 is susceptible to wireless Evil Twin attack since the MIM 
is in the same geographic location:
http://www.cnn.com/2005/TECH/internet/01/20/evil.twins/
  Depending on the ISP, a particular IP address within a class C netblock 
can be assigned anywhere in a 10-city area - possibly leading to false 
customer suspicions.

 Checklist item 1 is susceptible to type-alikes and font-alike attacks. 
It's easy to construct a scenario where a victim of the Evil Twin attack 
above types 'www.bankofamerica.com' into their browser and ends up at 
https://www.banckofamerica.com .  The victim is not likely to notice the 
extra 'c'.

 Expanding on the previous scenario, the Evil Twin will not be able to get 
the secure cookie and display the check number.  However, the habitual 
'cookie dumper' is used to signing in from an unrecognized PC and would 
probably proceed with a challenge-response.   All the MIM would need to do 
is echo the BofA screens directly and lift the login information.

  So we're pretty much back to
    1.)  Use SSL throughout the site as you suggest.
    2.)  Train users to recognize the proper site - how to look for and 
interpret the padlock information to validate that they're really talking to 
their bank.
    3.)  Book mark the SSL site to prevent typos taking them to a secure but 
type-alike phisher site.