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