From: Marco Aurelio dos Santos (marco.gsig.com.br)
Date: Thu Dec 23 2004 - 06:47:27 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In-Reply-To: <b841ffed0412092222217e0dc1mail.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 hackerbadguys.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-helpsecurityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <webappsec.list-id.securityfocus.com>
>List-Post: <mailto:webappsecsecurityfocus.com>
>List-Help: <mailto:webappsec-helpsecurityfocus.com>
>List-Unsubscribe: <mailto:webappsec-unsubscribesecurityfocus.com>
>List-Subscribe: <mailto:webappsec-subscribesecurityfocus.com>
>Delivered-To: mailing list webappsecsecurityfocus.com
>Delivered-To: moderator for webappsecsecurityfocus.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: <b841ffed0412092222217e0dc1mail.gmail.com>
>Date: Fri, 10 Dec 2004 17:22:32 +1100
>From: Michael Silk <michaelsilkgmail.com>
>Reply-To: Michael Silk <michaelsilkgmail.com>
>To: Christopher Canova <canovacearthlink.net>
>Subject: Re: Article - A solution to phishing
>Cc: webappsecsecurityfocus.com
>In-Reply-To: <3130619391631287612unknownmsgid>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: 7bit
>References: <b841ffed04112603221d374c15mail.gmail.com>
> <3130619391631287612unknownmsgid>
>
>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
><canovacearthlink.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:michaelsilkgmail.com]
>> Sent: Friday, November 26, 2004 3:23 AM
>> To: canovacearthlink.net; webappsecsecurityfocus.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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]