WebApp Sec mailing list archives
Re: Article - A solution to phishing
From: Marco Aurelio dos Santos <marco.gs () ig com br>
Date: 23 Dec 2004 12:47:27 -0000
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
Current thread:
- RE: Article - A solution to phishing, (continued)
- RE: Article - A solution to phishing WebAppSecurity [Technicalinfo.net] (Nov 30)
- RE: Article - A solution to phishing Michael Silk (Nov 30)
- Re: Article - A solution to phishing Jeremiah Grossman (Dec 01)
- Re: Article - A solution to phishing Adam Shostack (Dec 02)
- Re: Article - A solution to phishing [Passmark] Jeremiah Grossman (Dec 02)
- Re: Article - A solution to phishing Robert Hajime Lanning (Dec 02)
- Re: Article - A solution to phishing Jeremiah Grossman (Dec 01)
- RE: Article - A solution to phishing Michael Silk (Nov 30)
- Re: Article - A solution to phishing Jimi Thompson (Dec 01)
- RE: Article - A solution to phishing Damhuis Anton (Nov 30)
- Re: Article - A solution to phishing Marco Aurelio dos Santos (Dec 23)
- Re: Article - A solution to phishing Marco Aurelio dos Santos (Dec 23)
- Re: Article - A solution to phishing Michael Silk (Dec 28)
- Web Application Security Testing Procedures Lecia McCalla (Dec 30)
- Re: Web Application Security Testing Procedures HernĂ¡n M . Racciatti (Dec 30)
- Re: Web Application Security Testing Procedures Adam Tuliper (Dec 30)
- Re: Web Application Security Testing Procedures Saqib Ali (Dec 31)
- Web Application Security Testing Procedures Lecia McCalla (Dec 30)