[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Thu Jan 15 13:30:45 EST 2009


Plash,

Thanks for the idea. Please don't take my talks as overstatements, I just
wanted to have some innovative ideas from you guys.

Many organizations implement session mechanisms without using SSL. As a
matter of fact these are not the conditions that I have set. There are many
scenarios where using SSL is unworkable and in order to provide protection,
there are solutions.

Also, it becomes more relevant when people are trying to prove the
weaknesses of SSL. Not to forget, facts say that most organizations who use
SSL, use self signed certificates rather than a CA sign it.

For sessions on non-SSL, there are many undocumented solutions which can be
put into practice but such solutions needs to be well-reviewed and
well-tested before they are implemented. I have come to know about one of
the methods implemented by one of the top e-commerce portal giants. This
solution is a bit tough to understand and subsequently implement it. Before
I discuss it on the mailing list, I need to make sure that I understand it
well. The only thing I can share at the moment is, it uses time-stamps.
Hopefully, I would be discussing this proposition in detail in the upcoming
Delhi Chapter meeting this month.

Sorry if my talks were exaggerated. I still seek more ideas on the same
question if someone is willing to share.

Many thanks.

On Thu, Jan 15, 2009 at 11:29 PM, Plash Chowdhary
<plash.chowdhary at tcs.com>wrote:

>
> Gunwant,,
>
> Yes impractical "Off band validation" for each request in the conditions
> you have set. Now either you come up with a solution or im implimenting SSL
> *: )*
>
> Regards
> Plash
>
>
>  *"Gunwant Singh" <gunwant.s at gmail.com>*
>
> 01/15/2009 10:27 AM
>   To
> "Plash Chowdhary" <plash.chowdhary at tcs.com>  cc
> owasp-delhi at lists.owasp.org  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
> I would happily accept what you say if you say how it protects.
>
> Tell me **how** would a sniffer miss your validation code on an
> unencrypted channel. We should talk about mitigating not minimizing.
>
> Oh ! unless you are saying, a different off band validation code is sent
> for **each** request - then it is possible but it is impractical even in
> high risk applications.
>
> On Thu, Jan 15, 2009 at 9:41 PM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> It does Gunwant, Use long one time off band validation....and keep a short
> TTL it will minimize the risk of relpay,....
>
>
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
>
> 01/15/2009 09:25 AM
>
>   To
> "Plash Chowdhary" <*plash.chowdhary at tcs.com* <plash.chowdhary at tcs.com>>
> cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
> That doesn't affirm protection against replay attack, dude!
> In the transit, anyone can see your validation code...
> Even if you hash/encrypt it, still it can used to replay the traffic...
> this is vulnerable.. :)
>
> On Thu, Jan 15, 2009 at 3:46 AM, Plash Chowdhary <*plash.chowdhary at tcs.com
> * <plash.chowdhary at tcs.com>> wrote:
>
> verify user offline.. send an sms(or similar) with a validation code(long
> randomly genrated  string) to the user everytime he logs in to validate and
> use it everytime a transaction (high risk) is done or role is  changed..
> best way still will be to use it over SSL and use digital signatures
>
> Regards
> Plash
>
>
>   *"Gunwant Singh" <**gunwant.s at gmail.com* <gunwant.s at gmail.com>*>*
> Sent by: *owasp-delhi-bounces at lists.owasp.org*<owasp-delhi-bounces at lists.owasp.org>
>
> 01/14/2009 10:13 AM
>
>   To
> "Karthik Muthukrishnan" <*karthik.muthukrishnan at tcs.com*<karthik.muthukrishnan at tcs.com>
> >  cc
> *owasp-delhi at lists.owasp.org* <owasp-delhi at lists.owasp.org>  Subject
> Re: [Owasp-delhi] SSL Broken..
>
>
>
>
>
>
>
>
> Hi,
>
> 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* <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
> unencrypted.
>
> > 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
> _______________________________________________
> Owasp-delhi mailing list*
> **Owasp-delhi at lists.owasp.org* <Owasp-delhi at lists.owasp.org>*
> **https://lists.owasp.org/mailman/listinfo/owasp-delhi*<https://lists.owasp.org/mailman/listinfo/owasp-delhi>
>
> ForwardSourceID:NT00005236
> =====-----=====-----=====
> 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
>
> ForwardSourceID:NT000052F2
>
> =====-----=====-----=====
> 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
>
> ForwardSourceID:NT0000530E
>
> =====-----=====-----=====
> 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/20090116/10456797/attachment-0001.html 


More information about the Owasp-delhi mailing list