<font size="2" face="sans-serif"><br>&gt;rehashing everytime and time synch would
take considerable cycles. This organisation mite have git custom made hardware
to expidiate the process some thing like an ssl accelarater</font>
<br>
<br>--I am not going to care about how the organization is going to implement this stuff. I am just curious how good this technique can be. But its correct that this is going to be quite CPU intensive, the same way as SSL.<br>
<br><font size="2" face="sans-serif">&gt;But I feel like CA&#39;s it is also suceptable
to collision attacks....lets say they are using SHA-1, ans sha -1 becomes
vulnerable.. bith CA and this methodology goes down...</font>
<br><br>--Who says you can only use SHA-1/256? Changing your own implementation is not an issue instead of changing something that everyone is using like SSL.<br><br>&gt;<font size="2" face="sans-serif">when the client sends &quot;</font><font size="2">combined
has of message, password and the time-stamp</font><font size="2" face="sans-serif">&quot;
its like sending a digital signature ...whish has to be verified everytime....your
comments....??</font>
<br><br>--Correct, the same way as we do validate Session ID each time in typical web applications.<br><br><font size="2" face="sans-serif">&gt;One of my friend always said... if you
are making code more and more complex.. one thing is for sure you have
not understood teh reuirements .</font>
<br><font size="2" face="sans-serif">I think this falls in the same catagory
instead of using simple ssl with ssl accelarater they have complicate dthings
.. what do you say?</font>
<br><br><div class="gmail_quote">--So the whole point is I am not comparing this with SSL in the first place. I do
not want to replace SSL with this at all. Come on, this is just a draft
proposition of a thing that may deduce something helpful or may be not. So lets not involve what SSL can do and what this
technique cannot. SSL has its own place.<br><br>Thanks for your feedback.<br><br><br>On Sat, Jan 17, 2009 at 12:16 AM, Plash Chowdhary <span dir="ltr">&lt;<a href="mailto:plash.chowdhary@tcs.com">plash.chowdhary@tcs.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><font size="2" face="sans-serif">Gunwant,</font>
<br>
<br><font size="2" face="sans-serif">rehashing everytime and time synch would
take considerable cycles. This organisation mite have git custom made hardware
to expidiate the process some thing like an ssl accelarater</font>
<br>
<br><font size="2" face="sans-serif">&nbsp;i would say it is an innovative
different approch .....</font>
<br>
<br><font size="2" face="sans-serif">But I feel like CA&#39;s it is also suceptable
to collision attacks....lets say they are using SHA-1, ans sha -1 becomes
vulnerable.. bith CA and this methodology goes down...</font>
<br>
<br><font size="2" face="sans-serif">(My assumption is CA keys will be as
complex as combinatio of time, username , password and session)</font>
<br>
<br><font size="2" face="sans-serif">On second thoughs </font>
<br><font size="2" face="sans-serif">when the client sends &quot;</font><font size="2">combined
has of message, password and the time-stamp</font><font size="2" face="sans-serif">&quot;
its like sending a digital signature ...whish has to be verified everytime....your
comments....??</font>
<br>
<br><font size="2" face="sans-serif">One of my friend always said... if you
are making code more and more complex.. one thing is for sure you have
not understood teh reuirements .</font>
<br><font size="2" face="sans-serif">I think this falls in the same catagory
instead of using simple ssl with ssl accelarater they have complicate dthings
.. what do you say?</font>
<br>
<br>
<br><font size="2" face="sans-serif">regards</font>
<br><font size="2" face="sans-serif">Plash<br>
</font>
<br>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="40%"><font size="1" face="sans-serif"><b>&quot;Gunwant Singh&quot;
&lt;<a href="mailto:gunwant.s@gmail.com" target="_blank">gunwant.s@gmail.com</a>&gt;</b> </font>
<p><font size="1" face="sans-serif">01/16/2009 11:27 AM</font>
</p></td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td><font size="1" face="sans-serif">&quot;Plash Chowdhary&quot; &lt;<a href="mailto:plash.chowdhary@tcs.com" target="_blank">plash.chowdhary@tcs.com</a>&gt;</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: [Owasp-delhi] SSL Broken..</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table>
<br>
<br>
<br><font size="3">Hi,</font>
<p><font size="2">Ok, let me elucidate the workings of the technique I was
talking about.<br>
<br>
But before that I just want to shed some light on a few things so no-one
comes again questioning to me about these and start some endless argument.<br>
<br>
- The e-commerce site I was talking about, I never said that they are only
using the technique I am going to discuss. They might be using other techniques
for their protection. What I meant was I&#39;ve not seen/heard anyone else
using this technique. That doesn&#39;t mean that they are only using this technique
for their protection. Every giant incorporates multi-tier security for
their resources. &nbsp;I am not sure what exactly they are using besides
this technique as Nobody reveals that. &nbsp;I questioned someone on a
forum, he came up with this technique, I studied, checked this on their
documentation page, discussed with some people, discussed with some more,
argued with even more and now I am here. I am looking for some feedback
from you all. Just let me know what ever you think is wrong with this.
Anyhow the question is not that whether they are using it or not but the
question is &#39;How good is the technique?&#39;<br>
<br>
- Please don&#39;t misinterpret my statement. I am not saying &#39;Don&#39;t use SSL&#39;.
SSL is definitely a protection mechanism for &quot;Now&quot; if we use
it appropriately (CA signed certificate with a well-tested, well-reviewed
implementation). Use SSL till someone finds some exploit *practically*
not theoretically. This whole discussion is based on a research question
so I/we can get a *feasible* working solution for this (may-be-a-future)
problem. If you are not interested in discussing please do not comment.
And please do not envisage what I am not saying.<br>
<br>
So here is how it works.<br>
<br>
No SSL. All traffic in clear text.<br>
Initially we need to communicate an OOB password/code/nonce (whatever you
call it) to the client - only *once* not each time.</font>
</p><p><font size="2"><br>
1. The client initiates a connection request to the server. As a result,
server will initiate a handshake process to synchronize the time-stamps
between the client and itself. Then the server will analyze tolerance time
of packets leaving the client workstation till it reaches the server. The
tolerance time is configured so to manage slow hosts or slow traffic. In
plain words, server synchronizes date and time (in seconds, milliseconds
or even nanoseconds based on the criticality of the application) with the
client.</font>
</p><p><font size="2">2. At the client side: the message, instantaneous time-stamp
and the password are concatenated and hashed via SHA-1/SHA-256, whatever
one wishes. This ensuing hash is combined with the username to form an
authentication header and sent to the server. </font>
</p><p><font size="2">3. At the server side, the server sees the username and
perceives which user is trying to authenticate. Based on the tolerance
configured initially at the handshake time, it picks the time-stamp from
its own clock and using the password and the message it generates the hash
in the same way as it was done at the client side.</font>
</p><p><font size="2">4. If the hash matches it generates a Session ID and maps
it to the username of the user. This Session ID will be sent from the client
to the server along with the computed hash (which is different for each
request - see next Step) </font>
</p><p><font size="2">5. Now if the client sends another request, it appends
and then hashes the message, password and the time-stamp (which will be
apparently because of the different instantaneous time-stamp i.e. date
and time). This resulting string is sent to the server along with the Session
ID assigned to the user earlier. The resulting string contains a different
hash as the time has changed. This will be validated at the server the
same way as in Step 3.</font>
</p><p><font size="2">Now how can an adversary exploit this scenario? What I
think of are two ways:</font>
</p><p><font size="2">1. Either he will capture one of the hashes and try to
predict the next hash by brute forcing different time-stamps.</font>
</p><p><font size="2">- But this can not be possible. He doesn&#39;t have the password
to generate the hash.</font>
</p><p><font size="2">2. What if he captures a series of requests and responses
and replays them back to the server at a later stage.</font><font size="3">
</font>
</p><p><font size="2">- This can&#39;t be possible either. In order to interact with
the server, one needs to handshake so to synchronize itself with the server&#39;s
clock. The attacker would not be able to synchronize because he would not
be able to synchronize the *past-timestamp* (in the captured traffic) with
the server&#39;s current time. </font>
</p><p><font size="2">3. Lastly for the newbies, what if he captures the Session
ID.</font>
</p><p><font size="3">- But he would not be able to produce the matching Hash
for the request, so no luck.<br>
</font>
</p><p><font size="2">A few things to contemplate:</font>
</p><p><font size="2">1. This will be considerably be CPU intensive but can be
acknowledged if compared to the processing cycles SSL takes.</font>
</p><p><font size="2">2. Time synchronization can be complex. I have no idea
how to do that. </font>
</p><p><font size="2">3. Please provide your feedback/fury/antagonism/annoyance/appreciation/whatever.
Hope I explained this </font><font size="3">in a very straightforward way.</font>
</p><p><font size="2">Thanks.</font>
</p><p><font size="3">&nbsp;</font>
</p><p><font size="3"><br>
</font>
<br><font size="3">On Fri, Jan 16, 2009 at 4:26 AM, Plash Chowdhary &lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="3" color="blue"><u>plash.chowdhary@tcs.com</u></font></a><font size="3">&gt;
wrote:</font>
<br><font size="2" face="sans-serif"><br>
Gunwant,</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
I will be interested to know kind of soltutions are being used.</font><font size="3">
</font><font size="2" face="sans-serif"><br>
SInce you are talking about **Time stamp**(in clear text will be perdictable,
specially if a client side algo is being used) &lt;some random number in
hidden field with every request,&lt;unique captcha with every request (this
will be interesting) &nbsp;can be a case but they will be not as roboust
&nbsp;as out of band..</font><font size="3"> </font><font size="2" face="sans-serif"><br>
some how with Time stamps only thing that rings bell is CRYPTOGRAPHY <b>:
D </b>(PKI??)</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
I will be really surprized if that organization is not using SSL from a
Vendor. (as you said its an e commerce site)</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
and anyways i wont be using HTTPS on public content of my site and will
switch to HTTPS session only when needed (IDEALLY)</font><font size="3">
<br>
<br>
</font><font size="2" face="sans-serif"><br>
lemme know your thoughts</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
Regards</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Plash</font><font size="3"> <br>
</font><font size="2" face="sans-serif"><br>
</font><font size="3"><br>
<br>
<br>
</font>
</p><table width="100%">
<tbody><tr valign="top">
<td width="46%"><font size="1" face="sans-serif"><b>&quot;Gunwant Singh&quot;
&lt;</b></font><a href="mailto:gunwant.s@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><b><u>gunwant.s@gmail.com</u></b></font></a><font size="1" face="sans-serif"><b>&gt;</b>
</font>
<p><font size="1" face="sans-serif">01/15/2009 12:30 PM</font>
</p></td><td width="53%">
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="13%">
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td width="86%"><font size="1" face="sans-serif">&quot;Plash Chowdhary&quot;
&lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>plash.chowdhary@tcs.com</u></font></a><font size="1" face="sans-serif">&gt;</font><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><a href="mailto:owasp-delhi@lists.owasp.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>owasp-delhi@lists.owasp.org</u></font></a><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: [Owasp-delhi] SSL Broken..</font></td></tr></tbody></table>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="50%">
</td><td width="50%"></td></tr></tbody></table>
<br></td></tr></tbody></table>
<br><font size="3"><br>
<br>
<br>
Plash, <br>
<br>
Thanks for the idea. Please don&#39;t take my talks as overstatements, I just
wanted to have some innovative ideas from you guys.<br>
<br>
Many organizations implement session mechanisms without using SSL. As a
matter of fact these are not the conditions that I have set. There are
many scenarios where using SSL is unworkable and in order to provide protection,
there are solutions. <br>
<br>
Also, it becomes more relevant when people are trying to prove the weaknesses
of SSL. Not to forget, facts say that most organizations who use SSL, use
self signed certificates rather than a CA sign it. <br>
<br>
For sessions on non-SSL, there are many undocumented solutions which can
be put into practice but such solutions needs to be well-reviewed and well-tested
before they are implemented. I have come to know about one of the methods
implemented by one of the top e-commerce portal giants. This solution is
a bit tough to understand and subsequently implement it. Before I discuss
it on the mailing list, I need to make sure that I understand it well.
The only thing I can share at the moment is, it uses time-stamps. Hopefully,
I would be discussing this proposition in detail in the upcoming Delhi
Chapter meeting this month.<br>
<br>
Sorry if my talks were exaggerated. I still seek more ideas on the same
question if someone is willing to share. <br>
<br>
Many thanks. <br>
<br>
On Thu, Jan 15, 2009 at 11:29 PM, Plash Chowdhary &lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="3" color="blue"><u>plash.chowdhary@tcs.com</u></font></a><font size="3">&gt;
wrote: </font><font size="2" face="sans-serif"><br>
<br>
Gunwant,,</font><font size="3"> </font><font size="2" face="sans-serif"><br>
<br>
Yes impractical &quot;Off band validation&quot; for each request in the
conditions you have set. Now either you come up with a solution or im implimenting
SSL <b>: )</b></font><font size="3"> </font><font size="2" face="sans-serif"><br>
<br>
Regards</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Plash</font><font size="3"> <br>
</font>
<table width="100%">
<tbody><tr valign="top">
<td width="46%"><font size="1" face="sans-serif"><b>&quot;Gunwant Singh&quot;
&lt;</b></font><a href="mailto:gunwant.s@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><b><u>gunwant.s@gmail.com</u></b></font></a><font size="1" face="sans-serif"><b>&gt;</b>
</font>
<p><font size="1" face="sans-serif">01/15/2009 10:27 AM</font><font size="3">
</font>
</p></td><td width="53%">
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="13%">
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td width="86%"><font size="1" face="sans-serif">&quot;Plash Chowdhary&quot;
&lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>plash.chowdhary@tcs.com</u></font></a><font size="1" face="sans-serif">&gt;</font><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><a href="mailto:owasp-delhi@lists.owasp.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>owasp-delhi@lists.owasp.org</u></font></a><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: [Owasp-delhi] SSL Broken..</font></td></tr></tbody></table>
<br><font size="3"><br>
</font>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="50%">
</td><td width="50%"></td></tr></tbody></table>
<br></td></tr></tbody></table>
<br><font size="3"><br>
<br>
<br>
<br>
I would happily accept what you say if you say how it protects.<br>
<br>
Tell me <b>*how*</b> would a sniffer miss your validation code on an unencrypted
channel. We should talk about mitigating not minimizing.<br>
<br>
Oh ! unless you are saying, a different off band validation code is sent
for <b>*each*</b> request - then it is possible but it is impractical even
in high risk applications.<br>
<br>
On Thu, Jan 15, 2009 at 9:41 PM, Plash Chowdhary &lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="3" color="blue"><u>plash.chowdhary@tcs.com</u></font></a><font size="3">&gt;
wrote: </font><font size="2" face="sans-serif"><br>
<br>
It does Gunwant, Use long one time off band validation....and keep a short
TTL it will minimize the risk of relpay,....</font><font size="3"> <br>
</font>
<table width="100%">
<tbody><tr valign="top">
<td width="46%"><font size="1" face="sans-serif"><b>&quot;Gunwant Singh&quot;
&lt;</b></font><a href="mailto:gunwant.s@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><b><u>gunwant.s@gmail.com</u></b></font></a><font size="1" face="sans-serif"><b>&gt;</b>
</font>
<p><font size="1" face="sans-serif">01/15/2009 09:25 AM</font><font size="3">
</font>
</p></td><td width="53%">
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="13%">
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td width="86%"><font size="1" face="sans-serif">&quot;Plash Chowdhary&quot;
&lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>plash.chowdhary@tcs.com</u></font></a><font size="1" face="sans-serif">&gt;</font><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><a href="mailto:owasp-delhi@lists.owasp.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>owasp-delhi@lists.owasp.org</u></font></a><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: [Owasp-delhi] SSL Broken..</font></td></tr></tbody></table>
<br><font size="3"><br>
<br>
</font>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="50%">
</td><td width="50%"></td></tr></tbody></table>
<br></td></tr></tbody></table>
<br><font size="3"><br>
<br>
<br>
<br>
<br>
That doesn&#39;t affirm protection against replay attack, dude!<br>
In the transit, anyone can see your validation code...<br>
Even if you hash/encrypt it, still it can used to replay the traffic...<br>
this is vulnerable.. :)<br>
<br>
On Thu, Jan 15, 2009 at 3:46 AM, Plash Chowdhary &lt;</font><a href="mailto:plash.chowdhary@tcs.com" target="_blank"><font size="3" color="blue"><u>plash.chowdhary@tcs.com</u></font></a><font size="3">&gt;
wrote: </font><font size="2" face="sans-serif"><br>
<br>
verify user offline.. send an sms(or similar) with a validation code(long
randomly genrated &nbsp;string) to the user everytime he logs in to validate
and use it everytime a transaction (high risk) is done or role is &nbsp;changed..
best way still will be to use it over SSL and use digital signatures</font><font size="3">
</font><font size="2" face="sans-serif"><br>
<br>
Regards</font><font size="3"> </font><font size="2" face="sans-serif"><br>
Plash</font><font size="3"> <br>
</font>
<table width="100%">
<tbody><tr valign="top">
<td width="42%"><font size="1" face="sans-serif"><b>&quot;Gunwant Singh&quot;
&lt;</b></font><a href="mailto:gunwant.s@gmail.com" target="_blank"><font size="1" color="blue" face="sans-serif"><b><u>gunwant.s@gmail.com</u></b></font></a><font size="1" face="sans-serif"><b>&gt;</b>
<br>
Sent by: </font><a href="mailto:owasp-delhi-bounces@lists.owasp.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>owasp-delhi-bounces@lists.owasp.org</u></font></a><font size="3">
</font>
<p><font size="1" face="sans-serif">01/14/2009 10:13 AM</font><font size="3">
</font>
</p></td><td width="57%">
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="11%">
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td width="88%"><font size="1" face="sans-serif">&quot;Karthik Muthukrishnan&quot;
&lt;</font><a href="mailto:karthik.muthukrishnan@tcs.com" target="_blank"><font size="1" color="blue" face="sans-serif"><u>karthik.muthukrishnan@tcs.com</u></font></a><font size="1" face="sans-serif">&gt;</font><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><a href="mailto:owasp-delhi@lists.owasp.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>owasp-delhi@lists.owasp.org</u></font></a><font size="3">
</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: [Owasp-delhi] SSL Broken..</font></td></tr></tbody></table>
<br><font size="3"><br>
<br>
<br>
</font>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="50%">
</td><td width="50%"></td></tr></tbody></table>
<br></td></tr></tbody></table>
<br><font size="3"><br>
<br>
</font><font size="2" color="#4000a2" face="sans-serif"><br>
<br>
<br>
<br>
Hi,<br>
<br>
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&#39;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</font><font size="3" face="sans-serif">.
</font><font size="3" color="#4000a2" face="sans-serif">Please see the answers
below.</font><font size="3" face="sans-serif"><br>
<br>
On Wed, Jan 14, 2009 at 3:50 PM, Karthik Muthukrishnan &lt;</font><a href="mailto:karthik.muthukrishnan@tcs.com" target="_blank"><font size="3" color="blue" face="sans-serif"><u>karthik.muthukrishnan@tcs.com</u></font></a><font size="3" face="sans-serif">&gt;
wrote:</font><font size="3"> </font><font size="2" face="sans-serif"><br>
<br>
&gt; </font><font size="3" face="sans-serif">salted MD5 hashing protects
the authentication credentials rightly from eavesdropping on the network.
</font><font size="2" face="sans-serif"><br>
Salting is used to protect MD5 hashes from rainbow table attacks. </font><font size="3" color="#4000a2" face="Times New Roman"><br>
Apparently Yes, although ultimately it protects authentication credentials
only. Facts say the highest risk is eavesdropping if the session is unencrypted.</font><font size="3" face="sans-serif">
</font><font size="2" face="sans-serif"><br>
<br>
&gt; </font><font size="3" face="sans-serif">SSL does the same thing. </font><font size="2" face="sans-serif"><br>
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.</font><font size="3">
</font><font size="2" color="#4000a2" face="sans-serif"><br>
I know what SSL does, but my question is something else.</font><font size="3" face="sans-serif">
</font><font size="2" face="sans-serif"><br>
<br>
&gt; </font><font size="3" face="sans-serif">However, in some scenarios SSL
might not be feasible. For example, causing heavy load on the server or
may be some applications don&#39;t support it, etc. </font><font size="2" face="sans-serif"><br>
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.</font><font size="3" face="sans-serif">
</font>
<p><font size="3" color="#4000a2" face="sans-serif">Again my question is something
else. I know if SSL doesn&#39;t work, accelerators help expedite the processing.
What I want to know is, if I &quot;Do Not&quot; want to use SSL what measures
can be taken.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
<br>
<br>
&gt; </font><font size="3" face="sans-serif">We can protect the authentication
credentials using salted MD5 hashing or by using SSL. </font><font size="2" face="sans-serif"><br>
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.</font><font size="3" face="sans-serif"> </font><font size="3" color="#4000a2" face="sans-serif"><br>
So you are proclaiming that we *have to* rely &nbsp;on SSL- no other alternative.
<br>
Hashes are also used in many applications for many different purposes besides
authenticity and integrity.</font><font size="3"> </font><font size="2" face="sans-serif"><br>
<br>
<br>
&gt; </font><font size="3" face="sans-serif">In order to protect the Session
credentials (Session ID, tokens, cookies, etc) on a non-SSL channel what
measures can be taken? </font><font size="2" face="sans-serif"><br>
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. </font><font size="3" color="#4000a2" face="sans-serif"><br>
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. <br>
<br>
I just want to know &nbsp;if anyone has an idea on how it can be done if
h/she is willing to share that would be really appreciative.</font><font size="3" face="sans-serif">
</font><font size="3" color="#4000a2" face="sans-serif">Please make sure you
understand what I am looking for.<br>
No offence :)</font><font size="2" face="sans-serif"><br>
<br>
<br>
<br>
Karthik</font><font size="3"> </font><tt><font size="3"><br>
=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</font></tt><font size="3" face="sans-serif"><br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Gunwant Singh</font><font size="3"> </font><tt><font size="2"><br>
_______________________________________________<br>
Owasp-delhi mailing list</font></tt><font size="3" color="blue"><u><br>
</u></font><a href="mailto:Owasp-delhi@lists.owasp.org" target="_blank"><tt><font size="2" color="blue"><u>Owasp-delhi@lists.owasp.org</u></font></tt></a><font size="3" color="blue"><u><br>
</u></font><a href="https://lists.owasp.org/mailman/listinfo/owasp-delhi" target="_blank"><tt><font size="2" color="blue"><u>https://lists.owasp.org/mailman/listinfo/owasp-delhi</u></font></tt></a><font size="1" color="white" face="sans-serif"><br>

<br>
ForwardSourceID:NT00005236 &nbsp; &nbsp;</font><font size="3"> </font><tt><font size="3"><br>
=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you</font></tt><font size="3"><br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Gunwant Singh</font><font size="1" color="white" face="sans-serif"><br>
<br>
ForwardSourceID:NT000052F2 &nbsp; &nbsp;</font><font size="3"> </font>
</p><p><tt><font size="3">=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you<br>
</font></tt><font size="3"><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Gunwant Singh</font><font size="1" color="white" face="sans-serif"><br>
<br>
ForwardSourceID:NT0000530E &nbsp; &nbsp;</font><font size="3"> </font>
</p><p><tt><font size="3">=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you<br>
<br>
</font></tt><font size="3"><br>
<br>
<br>
<br>
<br>
-- <br>
Gunwant Singh<br>
</font>
<br><font size="1" color="white" face="sans-serif">ForwardSourceID:NT0000533A
&nbsp; &nbsp;</font><font size="3"> </font>
<br><tt><font size="3">=====-----=====-----=====<br>
Notice: The information contained in this e-mail<br>
message and/or attachments to it may contain <br>
confidential or privileged information. If you are <br>
not the intended recipient, any dissemination, use, <br>
review, distribution, printing or copying of the <br>
information contained in this e-mail message <br>
and/or attachments to it are strictly prohibited. If <br>
you have received this communication in error, <br>
please notify us by reply e-mail or telephone and <br>
immediately and permanently delete the message <br>
and any attachments. Thank you<br>
<br>
<br>
</font></tt>
<br><font size="3"><br>
<br>
<br>
-- <br>
Gunwant Singh<br>
</font>
<br><font size="1" color="white" face="sans-serif">ForwardSourceID:NT00005482
&nbsp; &nbsp;</font>
<br></p><pre>=====-----=====-----=====
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


</pre></blockquote></div><br><br clear="all"><br>-- <br>Gunwant Singh<br><br>