<P>yes karthik, I meant&nbsp;&nbsp;Out of band for every request...and that seemed to be only possible solution for rules alid by gunwant</P>
<P>regards</P>
<P>plash</P>
<P><BR><BR>Plash:<BR>Out of band verification must be done for every request to the server, if the session credentials (typically a session ID cookie) is to be protected. Without it, the initial auth creds in the login request will be protected by out of band verification, but not the session creds. <BR><BR>Gunwant:<BR>&gt; 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.<BR>Auth creds (login requests) of web applications can be protected by using either a challenge handshake mechanism or by using an out of band system. However both of these will only prevent clear-text auth creds from being transmitted across the network. After logging in, session credentials will have to be protected too. I beleive we have two options for this. The first is to encrypt the channel, which is most commonly used in web applications. The other alternative is not to support sessions at all. But this means that authentication must happen for every request going to the server.<BR><BR>Guys, let me know if you can think of other options for Gunwant's question.<BR><BR>&gt; &gt; As we all know salted MD5 hashing protects the authentication credentials rightly from eavesdropping on the network.<BR>&gt; Apparently Yes, although ultimately it protects authentication credentials only.<BR>No offense buddy, but you are using salted MD5 in a vulnerable way, for network apps. <BR><BR>Salted hashes prevent attackers from obtaining the source text, so by sniffing the network and obtaining the hash, they cant have the original password. You are correct there. <BR>But when a web app uses a login request with a hashed password, any one with that hash can use that to login to the app -- without needing the original password. <BR><BR>Ref: <BR><A href="http://en.wikipedia.org/wiki/Salt_(cryptography)">http://en.wikipedia.org/wiki/Salt_(cryptography)</A><BR><A href="http://msdn.microsoft.com/en-us/magazine/cc164107.aspx">http://msdn.microsoft.com/en-us/magazine/cc164107.aspx</A><BR><A href="http://en.wikipedia.org/wiki/Rainbow_table">http://en.wikipedia.org/wiki/Rainbow_table</A><BR><BR>Karthik<BR><BR><BR><FONT style="FONT-SIZE: 1pt" color=#ffffff>ForwardSourceID:NT000538DA </FONT></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>