Securily sending POST data without SSL ?

[Koobazaur]

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?

 

 

[448191]

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]

[448191]

Oh, and you would have to set the private key cookie empty before doing a XmlHTTPRequest (you can reset it afterwards), or the key will accompany the request, sending the private key over an insecure connection.

[Koobazaur]

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?

[448191]

In theory it should be possible to exploit visibility of an algorithms implementation, but I seriously doubt you can call that easy.

[448191]

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.

[Mastodont]

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.

 

I assume he wouldn't, if you use challenge-response method.

 

http://marakana.com/blog/examples/php-implementing-secure-login-with-php-javascript-and-sessions-without-ssl.html