Re: username and Password sent as clear text strings



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@xxxxxxxxxxxxxxxxx@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@xxxxxxxxxxxxxx>
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@xxxxxxxxxxx> 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
------------------------------------------------------------------------



Relevant Pages

  • Rolling my own vs SSL
    ... The client will come with the server ... The client and server first do a DH exchange using a pre-defined shared ... an encryption key for each direction, ... Many SSL implementations will cause unnecessary crypto algorithms to ...
    (sci.crypt)
  • Re: SSL Encryption Test
    ... Client side initiated SSL encryption and server-side SSL encryption. ... Server side SSL encryption is enabled via the "Force Protocol Encryption" ...
    (microsoft.public.sqlserver.security)
  • RE: Cannot decrypt files encrypted using Crypto API on a different
    ... previous message which uses the recipien't public key.) ... KEK (key encryption key) to protect the session key. ... embedded into your client app and server code). ... but what is the point to encrypt the data if ANYBODY can decrypt it (since ...
    (microsoft.public.platformsdk.security)
  • Re: username and Password sent as clear text strings
    ... encryption of the traffic. ... SSL is used. ... client, it would seem like too much hassle for a low possibility hack. ... This is how all web applications on the planet work today by design. ...
    (Pen-Test)
  • Re: Encrypted File Transfer
    ... step 1 thru 5 are essentially SSL. ... https is transparant, your PHP script and C# client ... > Server & Client establish HTTPS Connection. ... SSL does the encryption, so all you have to do is ...
    (comp.lang.php)