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.chowdh...@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" <gunwan...@gmail.com>* > > 01/15/2009 09:25 AM > To > "Plash Chowdhary" <plash.chowdh...@tcs.com> cc > owasp-delhi@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.chowdh...@tcs.com > * <plash.chowdh...@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" <**gunwan...@gmail.com* <gunwan...@gmail.com>*>* > Sent by: > *owasp-delhi-boun...@lists.owasp.org*<owasp-delhi-boun...@lists.owasp.org> > > 01/14/2009 10:13 AM > > To > "Karthik Muthukrishnan" > <*karthik.muthukrish...@tcs.com*<karthik.muthukrish...@tcs.com> > > cc > *owasp-de...@lists.owasp.org* <owasp-delhi@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.muthukrish...@tcs.com* <karthik.muthukrish...@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-de...@lists.owasp.org* <Owasp-delhi@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
_______________________________________________ Owasp-delhi mailing list Owasp-delhi@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-delhi
