Thank You Chris, the webapp is not coded by my cleint, its a third party app, I'll double check I don't think there is a configuration setting to require the transmitision of the username and password in a encrypted format.
The problem I'm having with all of this is:
My cleint is currently running this WebApp on all of there WIn2k3 Domain Controllers and Member Servers. Guess who is logging in.... Domain Admins.........I just don't want to see a MITM attack or SSL Failure allow a domain admin account to be compromised.
Since they all log into the same domain, i was going to use a certificate.
I want to thank everyone that has shared there thoughts so far, I've learned alot from this exchange of ideas.
Take Care and Have Fun --John
-------------- Original message ----------------------
From: christopher.riley_at_r-it.at
> An IPSEC solution would put extra load on the server and clients for
> encryption of the traffic. It would also possibly cause problems if the
> users are remote and not part of the domain, as you will need to use
> either a certificate or a PSK (pre-shared key) for the IPSEC. A PSK is
> obviously easier to implement, but weaker than the certificate option.
>
> From my view a simpler option would be to recommend that the webapp only
> transmits username password in encrytped format across the wire even when
> SSL is used. Adding another layer of on the wire encryption is just a
> little overkill for something that might or might not be an issue. For the
> client, it would seem like too much hassle for a low possibility hack. If
> the SSL is working then nothing on the wire should be visible in clear
> text. If a Man in the Middle attack of SSL failure (see Debian for
> details) occurs, then the important details of the traffic are still
> encrypted using whatever scheme the client decides on.
>
> Chris
>
> listbounce_at_securityfocus.com_at_inet wrote on 17.05.2008 01:52:14:
>
> > 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 intransit).
> >
> > 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_at_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_at_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
> > ------------------------------------------------------------------------
> >
>
>
> ----------------------------------------
> Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, DVR
> 0486809, UID ATU 16351908
>
> Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail dient
> ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen
> ueber dieses Medium nicht ausgetauscht werden.
> Correspondence with above mentioned sender via e-mail is only for information
> purposes. This medium may not be used for exchange of legally-binding
> communications.
> ----------------------------------------
>
>
> ------------------------------------------------------------------------
> 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
> ------------------------------------------------------------------------
>
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Received on May 21 2008
Intro
