Penetration Testing mailing list archives
RE: username and Password sent as clear text strings
From: "Shenk, Jerry A" <jshenk () decommunications com>
Date: Sat, 17 May 2008 09:13:38 -0400
I think that sounds like a good solution. You could even limit the ipsec communication to only encrypt (allow) traffic to this particular web server over port 443. You might want to encrypt traffic over 80 also if the client does and initial unencrypted connection....I'd vote to just turn off port 80 connections on that box but that's a whole different discussion. -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of jfvanmeter () comcast net Sent: Friday, May 16, 2008 6:37 PM To: pen-test () securityfocus com Subject: Re: username and Password sent as clear text strings What does everyone think of implementing a IPSEC solution to resolve the issue that we've all be talking about. The following are the reason I was thinking of IPSEC: SSL was designed for client application-to-server application authentication and encryption. IPsec can be used end-to-end I think the best scenario would be to implement both AH and ESP, AH provides data origin authentication and data integrity for the entire IP packet (with the exception of some fields in the IP header that must change in transit). ESP provides data confidentiality, data origin authentication, and data integrity for the IP payload. ESP with encryption uses an encryption algorithm (DES or 3DES) to provide data confidentiality, data origin authentication, and data integrity for the ESP payload. The reason to implement both AH and ESP is to protect the IP header -------------- Original message ---------------------- From: "Arian J. Evans" <arian.evans () anachronic com>
Let me summarize the previous responses and be very clear: This is how web applications work. All of them. There is no effectively way to "hash or encrypted" the password via client-side scripting. There are ways to do it, but in a web application all the code to do this is passed to the client from the server, making it pointless. It is similar to the problem in cryptography of passing the key with the message, but worse. It's passing the key, algorithm, comments, and message all together. In this type of environment it's not possible to do this securely. Hence the use of SSL for transport-layer security. Now...that said, some folks use SWFs and Adobe Air and such for trying to encrypt data in transit, especially if they are using AMF or some binary protocol, but again since everything has to be passed to the client it is completely trivial to reverse engineer. So, again, to conclude: This is how all web applications on the planet work today by design. You can reply to this if you would like to ask more questions, but unfortunately the SF pen-test list is one of the only ones that blocks posts from gmail forwarders so I do not think that you will see my post on the actual list. -- -- Arian J. Evans, software security stuff. I spend most of my money on motorcycles, mistresses, and martinis. The rest of it I squander. On Wed, May 14, 2008 at 3:39 AM, <jfvanmeter () comcast net> wrote:Hello everyone, and I know this might not be the most correct place
to post
this questions, but I was hoping to get some feedback on what you
think the
potential risk would be and how this this could be exploited.I completed a security review of a web server, that creates a SSL
connection
between the cleint and the server. Using WebScarab, I could see that
the
username and password are sent as clear text strings. The log in to
the server
requires a administrative account.Do you think there is a large amount of risk, in sending the
username and
password as a clear text string, since the pipe is encrypted? I was
thinking
that a man-in-the-middle or sometype of session hijacking attack
could allow
the account to be compromised.I'm working on completing the report for my client and was hoping
to get some
feedback from everyone so I could pose this to them correcly.Thank you in advance --John
------------------------------------------------------------------------ This list is sponsored by: Cenzic Top 5 Common Mistakes in Securing Web Applications Find out now! Get Webinar Recording and PPT Slides www.cenzic.com/landing/securityfocus/hackinar ------------------------------------------------------------------------ **DISCLAIMER This e-mail message and any files transmitted with it are intended for the use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business. ------------------------------------------------------------------------ This list is sponsored by: Cenzic Top 5 Common Mistakes in Securing Web Applications Find out now! Get Webinar Recording and PPT Slides www.cenzic.com/landing/securityfocus/hackinar ------------------------------------------------------------------------
Current thread:
- Re: username and Password sent as clear text strings, (continued)
- Re: username and Password sent as clear text strings Matthew Zimmerman (May 19)
- Re: username and Password sent as clear text strings David Howe (May 21)
- Re: username and Password sent as clear text strings Matthew Zimmerman (May 22)
- Re: username and Password sent as clear text strings David Howe (May 23)
- Re: username and Password sent as clear text strings David Howe (May 21)
- Re: username and Password sent as clear text strings Matthew Zimmerman (May 19)
- Re: username and Password sent as clear text strings christopher . riley (May 15)
- Re: username and Password sent as clear text strings jfvanmeter (May 15)
- RE: username and Password sent as clear text strings jfvanmeter (May 15)
- RE: username and Password sent as clear text strings dseth (May 15)
- RE: username and Password sent as clear text strings jfvanmeter (May 16)
- Re: username and Password sent as clear text strings jfvanmeter (May 16)
- RE: username and Password sent as clear text strings Shenk, Jerry A (May 17)
- Re: username and Password sent as clear text strings jfvanmeter (May 16)
- Re: username and Password sent as clear text strings arvind doraiswamy (May 18)
- Re: username and Password sent as clear text strings Orlin Gueorguiev (May 18)
- RE: username and Password sent as clear text strings Shenk, Jerry A (May 18)
- RE: username and Password sent as clear text strings Marvin Simkin (May 19)
- Re: username and Password sent as clear text strings jfvanmeter (May 19)
- Re: username and Password sent as clear text strings christopher . riley (May 19)
- Re: username and Password sent as clear text strings jfvanmeter (May 21)
- RE: username and Password sent as clear text strings Shenk, Jerry A (May 22)
- RE: username and Password sent as clear text strings John Babio (May 22)
- RE: username and Password sent as clear text strings Shenk, Jerry A (May 22)