[Owasp-delhi] SSL Broken..

Gunwant Singh gunwant.s at gmail.com
Thu Jan 15 10:35:36 EST 2009


>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.

So can you explain how will you implement these actually.

>No offense buddy, but you are using salted MD5 in a vulnerable way, for
network apps.
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.
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.

ok, but if you know in salted md5 hashing, highly random salt is
concatenated to the password hash which is again hashed to randomize the
concatenation. Perhaps, how would that hash be same all the time while in
transit? You can't use it to replay. Can you explain how else is it
vulnerable? So I am not talking about just hashing but salted hashing
wherein random salt makes the hashing dynamic each time it is sent to the
server. If you are curious enough check out the salted md5 hashing code at
my blogspot (gunwantsingh.blogspot.com).

- Gunwant


On Thu, Jan 15, 2009 at 2:05 PM, Karthik Muthukrishnan <
karthik.muthukrishnan at tcs.com> wrote:

>
> Plash:
> 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.
>
> Gunwant:
> > 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.
> 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.
>
> Guys, let me know if you can think of other options for Gunwant's question.
>
> > > As we all know salted MD5 hashing protects the authentication
> credentials rightly from eavesdropping on the network.
> > Apparently Yes, although ultimately it protects authentication
> credentials only.
> No offense buddy, but you are using salted MD5 in a vulnerable way, for
> network apps.
>
> 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.
> 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.
>
> Ref:
> http://en.wikipedia.org/wiki/Salt_(cryptography)<http://en.wikipedia.org/wiki/Salt_%28cryptography%29>
> http://msdn.microsoft.com/en-us/magazine/cc164107.aspx
> http://en.wikipedia.org/wiki/Rainbow_table
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-delhi/attachments/20090115/2ec0c7c6/attachment-0001.html 


More information about the Owasp-delhi mailing list