[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Wed Jan 14 11:13:21 EST 2009


Thanks for your reply but that did not answer my question. You are telling
me what I can use for protecting the credentials. I know what I can use, but
just out of curiousity I want to know if I don't use SSL/VPN or any other
network based protection, what else can be done on the application layer in
order to protect the credentials. Please see the answers below.

On Wed, Jan 14, 2009 at 3:50 PM, Karthik Muthukrishnan <
karthik.muthukrishnan at tcs.com> wrote:

> > salted MD5 hashing protects the authentication credentials rightly from
> eavesdropping on the network.
> Salting is used to protect MD5 hashes from rainbow table attacks.

Apparently Yes, although ultimately it protects authentication credentials
only. Facts say the highest risk is eavesdropping if the session is

> > SSL does the same thing.
> Yes, SSL is used to ensure confidentiality and trust in the network
> communiation. Confidentiality (or prevention of network eavesdropping) is
> ensured by encryption. Trust is accomplished by Server and/or client
> certificates.

I know what SSL does, but my question is something else.

> > However, in some scenarios SSL might not be feasible. For example,
> causing heavy load on the server or may be some applications don't support
> it, etc.
> In such cases SSL Accelerators are used. They are devices which can be fit
> into the architecture without changing the application or affecting the load
> on the application server.

Again my question is something else. I know if SSL doesn't work,
accelerators help expedite the processing. What I want to know is, if I "Do
Not" want to use SSL what measures can be taken.

> > We can protect the authentication credentials using salted MD5 hashing
> or by using SSL.
> To protect authentication credentials in HTTP, we have to rely on SSL.
> Hashes are a secure (aka not in clear text) way to store authentication
> credentials.

So you are proclaiming that we *have to* rely  on SSL- no other alternative.

Hashes are also used in many applications for many different purposes
besides authenticity and integrity.

> > In order to protect the Session credentials (Session ID, tokens,
> cookies, etc) on a non-SSL channel what measures can be taken?
> To protect either auth or session credentials we have to ensure
> confidentiality of the communication channel. If we dont use HTTPS, then VPN
> might be another option. While authentication credentials can be protected
> by some challenge handshake mechanism (similar to CHAP), we would need to
> protect session creds by encrypting the channel.

I was asking that if we can provide some protection on the application level
rather than on the network level. Besides SSL/VPN there are many options
available for protecting the authentication credentials. I want to know
(just out of curiousity) that how can we secure the session credentials on
an unencrypted/non-SSL channel. I know this will take too much processing
cycles, time synchronization, quantization in milliseconds even nanoseconds,
affirmation of the key exchange, dynamic hashing key generation to mitigate
replay attacks, and even more.

I just want to know  if anyone has an idea on how it can be done if h/she is
willing to share that would be really appreciative. Please make sure you
understand what I am looking for.
No offence :)

> Karthik
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you

Gunwant Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090114/bd5c8a68/attachment-0001.html 

More information about the Owasp-delhi mailing list