[Owasp-delhi] SSL Broken..

Tarun Dua tarundua at gmail.com
Thu Jan 15 03:53:31 EST 2009


Use a token that is generated on the client side constantly changes
'randomly' everytime one logs in or in a short time duration(e.g. RSA
token key that most corporates seem to use), even if it gets sent in
plaintext the time to compromise an account is short.
-Tarun

On Thu, Jan 15, 2009 at 4:10 AM, Plash Chowdhary
<plash.chowdhary at tcs.com> wrote:
>
> read "verify user offline" as "verify user out of band" was notgetting the
> exact word earlier
>
>
>
>
> Plash Chowdhary/DEL/TCS
>
> 01/14/2009 04:16 PM
>
> To
> "Gunwant Singh" <gunwant.s at gmail.com>
> cc
> "Karthik Muthukrishnan" <karthik.muthukrishnan at tcs.com>,
> owasp-delhi at lists.owasp.org, owasp-delhi-bounces at lists.owasp.org
> Subject
> Re: [Owasp-delhi] SSL Broken..Link
>
>
>
> 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
>
> ForwardSourceID:NT0000523E
>
> =====-----=====-----=====
> 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 at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-delhi
>
>


More information about the Owasp-delhi mailing list