Re: Article - A solution to phishing

[Marco Aurelio dos Santos <marco.gs () ig com br>]

In-Reply-To: <b841ffed0412092222217e0dc1 () mail gmail com>

Michael, I really don't see how this would prevent phishing. Because, you see, the user should inform his/her e-mail 
address at some point, and have the option to inform of address changing. To do this, the user probably would enter 
username/password (at this point, the bank doesn't have the user's e-mail). If the hacker has access to THIS password, 
through social engineering or any other way? He could then inform hacker () badguys com as the user e-mail, and begin 
receiving the temporary passwords from the bank.
Am I missing something here?

Regards

Marco


> Received: (qmail 17449 invoked from network); 14 Dec 2004 18:24:49 -0000
> Received: from outgoing.securityfocus.com (HELO outgoing3.securityfocus.com) (205.206.231.27)
>  by mail.securityfocus.com with SMTP; 14 Dec 2004 18:24:49 -0000
> Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])
>       by outgoing3.securityfocus.com (Postfix) with QMQP
>       id BBE25243FCB; Tue, 14 Dec 2004 09:35:52 -0700 (MST)
> Mailing-List: contact webappsec-help () securityfocus com; run by ezmlm
> Precedence: bulk
> List-Id: <webappsec.list-id.securityfocus.com>
> List-Post: <mailto:webappsec () securityfocus com>
> List-Help: <mailto:webappsec-help () securityfocus com>
> List-Unsubscribe: <mailto:webappsec-unsubscribe () securityfocus com>
> List-Subscribe: <mailto:webappsec-subscribe () securityfocus com>
> Delivered-To: mailing list webappsec () securityfocus com
> Delivered-To: moderator for webappsec () securityfocus com
> Received: (qmail 25917 invoked from network); 10 Dec 2004 06:23:24 -0000
> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
>        s=beta; d=gmail.com;
>        
> h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
>        
> b=PICXvvixcZZX6I3WbWKtb4veyOrcr3Q8Hl8y8SiIIkTOraQvBfpqahZwA8+WL+KRYiuzQ5jfFSkyoCLCS7VGQP0yBzObuJWnC+gt6CIBy3Y+FtdNHo4TA4iFrOK9zW9hUsCjkw/p7wVCcp3lRVhob2GYCHy8f+wADk/8M+2qCoQ=
> Message-ID: <b841ffed0412092222217e0dc1 () mail gmail com>
> Date: Fri, 10 Dec 2004 17:22:32 +1100
> From: Michael Silk <michaelsilk () gmail com>
> Reply-To: Michael Silk <michaelsilk () gmail com>
> To: Christopher Canova <canovac () earthlink net>
> Subject: Re: Article - A solution to phishing
> Cc: webappsec () securityfocus com
> In-Reply-To: <3130619391631287612@unknownmsgid>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> References: <b841ffed04112603221d374c15 () mail gmail com>
>        <3130619391631287612@unknownmsgid>
>
> Just like it's worked to stop crime.
>
> ...
>
> Don't kid yourself - for offenders to be prosecuted their relative
> countries would need to respect and implement the appropriate laws. I
> can't see this happening very soon.
>
> Not to mention that possible punishment isn't a very effective method
> to stop people perform this action ... people will continue to do it,
> no matter what the punishment, if the reward is great.
>
> Technological solutions should be considered and, as discussed in this
> thread, a few nice solutions exist ... client authenticated SSL, etc.
>
> -- Michael
>
>
>
>
> On Thu, 9 Dec 2004 20:13:00 -0800, Christopher Canova
> <canovac () earthlink net> wrote:
> > http://www.snpx.com/cgi-bin/news5.cgi?target=www.newsnow.co.uk/cgi/NGoto/786
> > 26317?-2622
> >
> > Like I said... Tough legislation and pro-active prosecution will end
> > phishing scams, not simply using a new anti-phishing scheme.
> >
> >
> >
> > -----Original Message-----
> > From: Michael Silk [mailto:michaelsilk () gmail com]
> > Sent: Friday, November 26, 2004 3:23 AM
> > To: canovac () earthlink net; webappsec () securityfocus com
> > Subject: RE: Article - A solution to phishing
> >
> > Hi Christopher,
> >
> >        Thanks for your feedback, let me address it.
> >
> >        First let me say that many people have raised
> >        the issue (privately) of unecrypted emails not
> >        being good enough - and they have a point. So
> >        from now onwards let us assume that public
> >        key/private key exchange system is used to
> >        communicate the emails such that:
> >
> >        The user either provides their own public key
> >        to the site ("Test-Bank") or is given one upon
> >        registration.
> >
> >        Hence, emails between Test-Bank and Jones are
> >        encrypted and cannot be decrypted until Jones
> >        either:
> >                a) Types in pass-phrase _TO THE EMAIL CLIENT_.
> >                b) Connects USB device holding private key
> >                        to computer.
> >                c) Something else you can dream up involving
> >                        smart-cards.
> >
> >        The point is that the email is encrypted and can
> >        only be decrypted until such time as Jones and
> >        his password holding device (possibly his head)
> >        are at the computer.
> >
> >        Let's now address your points.
> >
> >        > * The password timeout is too short. Consider
> >        > that the default check frequency for most mail
> >        > programs is 30 minutes. Of course, this could be
> >        > fixed by making a longer timeout.
> >
> >        Timeout isn't required anymore (or at least isn't
> >        required to be short - can be 1 day or more) because
> >        email interception has become useless.
> >
> >        > * "A little bit of education" is exactly what
> >        > we need. If we had a "little bit of education"
> >        > to go around, then we would all be savvy users.
> >        > You're assuming that a normal user would be
> >        > interested in learning this method...
> >
> >        It is a simple method for them to adopt as opposed
> >        to reading warnings from Internet Explorer and being
> >        allowed to continue anyway ... or looking for a padlock,
> >        or looking at the address bar. In this case they have
> >        no choice but to accept the system, they cannot -
> >        without great and thought-out effort - pass the password
> >        to someone else before they use it.
> >
> >        > * Consider that the average time for a user to
> >        > become disinterested in the website they are
> >        > visiting is measured in seconds or minutes. If
> >        > this system was implemented in a site that provided
> >        > online merchandise, this lag would be unacceptable
> >        > for most, if not all, merchandisers. If the users
> >        > are waiting around for an email, the chances are
> >        > dramatically increased that they will move to a
> >        > different site that doesn't have this method
> >        > implemented.
> >
> >        The solution isn't appropriate for every site out there.
> >        A merchandiser wasn't my target. But you are correct,
> >        it is more bulky then a common login screen.
> >
> >        > * It is not secure. The email would need to be
> >        > encrypted. The encryption requires another password.
> >        > All the phisher would have to do is pose as someone
> >        > requiring the password for the encrypted email as
> >        > opposed to the password for the website. Of course,
> >        > this could cause the user to become
> >        > more suspicious.
> >
> >        The email is encrypted now. The phisher would not
> >        have the possibility to ask for the password as the
> >        user does not enter the password onto any website
> >        when they use it. It is used fully within their email
> >        client, or, ideally - it is used without them even
> >        being really aware, via usb or palm pilot or, as
> >        Pete Simpson mention [1] mobile phone.
> >
> >        > * Easier methods for one-time passwords are already
> >        > being used, and have been for some time. For example,
> >        > I remember at my work that we had this program which
> >        > would generate 5 random words for every login we attempt.
> >        > The program would accept a secret passphrase that only
> >        > the user knew and would only be installed on the
> >        > local system of the user. It would generate the five
> >        > words and the server would accept that passphrase only
> >        > once. Once the session is ended, that passphrase is no
> >        > longer available. This effectively eliminates the
> >        > requirement for waiting for an email.
> >
> >        I don't quite understand this description.
> >
> >        Are you saying the user has a passphrase which they enter
> >        into a program installed on their local system which would
> >        then generate 5 "random" words ?
> >
> >        It sounds a little different to the common web login
> >        scenario. Can you explain more ?
> >
> >        Could the user be tricked into typing his/her password
> >        somewhere other then the secure site ? It sounds like it
> >        - unless the program installed on the client computer
> >        performs the login function.
> >
> >        If it does, then it sounds almost identical to my system
> >        except that instead of requiring a tool installed on the
> >        clients computer we make use of their email system.
> >
> >        How does your communicate to the server to get the 5 random
> >        words ? Or are the words generated on the basis of some
> >        algorithm which the server decodes to realise that it is a
> >        certain user ?
> >
> >        > * However, even if you did implement a one time
> >        > password policy, so what? Phishing is a social attack.
> >        > It's not a passphrase attack.
> >
> >        Well actually it is. All phishing attemts I've seen, lately,
> >        try and grab your password. Perhaps there are others that
> >        try and grab other information but that is not to say that
> >        password-gathering "fake" websites don't exist - they do, and
> >        they are an issue. This system attempts to address that.
> >
> >        > Phishing doesn't
> >        > only gather passphrases, it can gather social security
> >        > numbers, credit card information, birth dates, etc. You're
> >        > not fixing anything by implementing a new, less effective
> >        > method for password generation.
> >
> >        We're fixing the fact that the user now has no, greatly
> >        useful, information to give away to the phisher - hence the
> >        phisher has nothing to phish for. No phish.
> >
> >        > So you are assuming LOTS of things in your blog, and the
> >        > worst assumption you make is that your system will work.
> >        > It's got lots of holes and doesn't focus on the fact that
> >        > HUMANS are susceptible to phishing,
> >
> >        Actually it does. Like I mentioned ahove the goal of the
> >        article was to take away from the user any information
> >        they could provide to the phisher (accidently). And we have
> >        done