[Owasp-delhi] SSL Broken..

Karthik Muthukrishnan karthik.muthukrishnan at tcs.com
Fri Jan 16 09:39:15 EST 2009


> 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.
Yes,  one time passcodes for each request. We have seen some banking 
applications use this approach for *each* high risk request.

Karthik

--
Karthik Muthukrishnan, CISSP - ISSAP,
Security Consultant




"Gunwant Singh" <gunwant.s at gmail.com> 
Sent by: owasp-delhi-bounces at lists.owasp.org
01/15/2009 06:27 PM

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> 
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> 
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> 
Sent by: owasp-delhi-bounces at lists.owasp.org 
01/14/2009 10:13 AM 


To
"Karthik Muthukrishnan" <karthik.muthukrishnan at tcs.com> 
cc
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> 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
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
_______________________________________________
Owasp-delhi mailing list
Owasp-delhi at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-delhi

ForwardSourceID:NT00011A22 
=====-----=====-----=====
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090116/c50c8b31/attachment-0001.html 


More information about the Owasp-delhi mailing list