[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Thu Jan 15 11:27:42 EST 2009


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>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>*
>
> 01/15/2009 09:25 AM
>   To
> "Plash Chowdhary" <plash.chowdhary at tcs.com>  cc
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090115/1c6b5b20/attachment-0001.html 


More information about the Owasp-delhi mailing list