Jump to content

Securily sending POST data without SSL ?


Koobazaur

Recommended Posts

Greetings,

 

Just as in many other web applications, I am faced with creating a secure login applet for my users. Naturally, the first thing that comes to mind is SSL. However, implementing that on my webhost is somewhat of a nuisance, so I was wondering about other protection methods I could implement.

 

I have noticed that a lot of websites (facebook, this forum etc.) don't use SSL. I am curious as to how that is achieved, as implementing secure login without SSL whatsoever would make the whole process much easier (and cheaper).

 

Any suggestions on how to achieve that / how all these other sites manage to be secure without SSL ?

 

Scooping up the page source code, I noticed that one webforum dynamically encoded the passwords with md5 via javascript and sent the encoded stuff via POST. Sounds like a great choice, but still easily hackable, if I understand. I mean, the biggest reason behind using SSL is to prevent someone reading the network traffic from getting the username/password. So if someone sees an encrypted password being transfered, it's useless to him since it's encrypted, right? Well, wrong. He could simply take the encrypted password and send it directly via POST (with the username) and he would, likewise, get access to the site. He wouldn't even need to know what the decrypted password is. Of course, I could also check to make sure the referer came from my own site to ensure someone can't do that, but then they could simply plug in the encrypted password in the login box and disable javascript in their browser (to prevent double-encryption) and would get in like that.

 

Any suggestions?

 

 

Link to comment
Share on other sites

Hijacking a HTTP session is difficult, the attacker needs to know a number of variables, as well as have perfect timing. A hacker is not likely to go through this amount of trouble unless the rewards are considerable. A high profile app like GMail uses SSL because it's an attractive target.

 

If you don't want/can't use SSL, there are other ways to ensure a secure login. One of which is mimicking a Public Key Infrastructure. This however relies on the secrecy of the private key. You would have to put in considerable effort to provide the client with it, without linking it to a HTTP session. In effect, you would have to do this by a separate channel, say email, and provide a means for a client to store/use this key.

 

One way to do this would be to provide the client with a browser plugin that can encode the request data sent to a server using an integrated key. This would mean the whole plugin would have to be compiled for every user. The plugin would have to able to decode responses as well.

 

An easier, but less safe way would be to use javascript. To avoid sending unencoded data, you would have to use XmlHttpRequest for all your requests. The private key could then become vulnerable to XSS attacks though. You could use the session id as a private key (if you do, at least set the algorithm to sha1), but remember it is sent to the client unencoded, and thus could be intercepted. The diagram below illustrates how this could work.

 

Google will provide you with some ready-to-use scripts to encode and decode.

 

[attachment deleted by admin]

Link to comment
Share on other sites

Thanks for the tips. I don't want my user to have to manually download a key / browser plugin as that's just a lot of hassle. As for Javascript encoding, wouldn't it be true that someone who simply looks up the page source code could figure out all the details of how the encryption works and, thus, easily crack it?

Link to comment
Share on other sites

Thanks for the tips. I don't want my user to have to manually download a key / browser plugin as that's just a lot of hassle. As for Javascript encoding, wouldn't it be true that someone who simply looks up the page source code could figure out all the details of how the encryption works and, thus, easily crack it?

 

You could also compile a Java applet. The private key would still have to be stored in a cookie, so it's still vulnerable to XSS.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.