views:

171

answers:

4

I know that using SSL is one way to do this. I go to websites like Facebook and LinkedIn and see that they only use https when they are dealing with sensitive data like passwords and personal settings. How is this done? How are they able to implement https on some websites while using http on others, while still remaining secure, or are they?

A: 

Their HTTP sites are not secure -- typically, the overhead of HTTPS is considered unnecessary when dealing with things like social networking logins. For example, StackOverflow is insecure -- somebody with a network sniffer could intercept a login cookie and impersonate a user.

If you just need to check that a login is valid, and don't care much about usability, you can use digest authentication. It provides a safe, secure way to transmit a username and password over HTTP. Of course, any data sent back from the site, or submitted by the user, is vulnerable to sniffing.

Short version: If you need security, use HTTPS. You can even get a free certificate, from sites like CAcert.

John Millikin
Yes, HTTPS is only used to protect the password. This is common in security systems, though.
Mark
CAcert is not a root CA - you may as well self-sign at that point.
firebird84
Or, let me rephrase - it's not a root CA as recognized by Firefox, and probably not IE either.
firebird84
See http://wiki.cacert.org/wiki/InclusionStatus
Gumbo
Start.com is included in Firefox.
erickson
No, self-signing is almost entirely useless. CAcert isn't a default root, but it can be used to provide verification that there's nobody performing a man-in-the-middle attack.
John Millikin
+1  A: 

This approach isn’t secure. Well it is secure when using HTTPS but once you’ve switched to HTTP all data is being transmitted over an unencrypted line. The session ID cookie (or the status and user identifiction is maintained) as well. So there’s still a gap to steal that information on the unencrypted line and try to impersonate you.

But this two-lane approach is common. Because HTTPS has some disadvantages. One is that is expensive (encrypting outgoing and decrypting incoming data) and another is that it disables at least public caching.

Gumbo
A: 

It depends on what you are trying to protect and how much hassle you want for the user, if you are not using https.

You can selectively encrypt the data in javascript so that only sensitive information is protected, but that is risky as anything done in javascript can be reverse-engineered.

You can look at my answer here for one way to do it in javascript: http://stackoverflow.com/questions/760273/how-do-i-encrypt-post-data-while-using-ajax-and-jquery/760324#760324

If you just don't want the data to be modified while being transmitted you can get create a hash, or convert the data to a hash if you saved it as a hash. Passwords are often saved as a hash, so this would make sense for them.

You can do all of this in javascript, but it will slow down transmitting the data.

If you are using webservices, which also go through http, then these options also work, but they can be faster as the program would not be in javascript.

James Black
A: 

There is a lot more to security than just HTTP/HTTPS. These are just to keep data from being read while on the wire.

The easiest way to do an HTTPS request on an HTTP site is via a form who's action is https://yoursite/login or something similar. This would cause you to go to that page and often these pages have a return to where you came from or forward you to a home page. That is how Facebook does it. The rest of the site is considered relatively secure because of access controls that are to make sure that those who have permission to view something are the only ones who may do so. This does not protect against Wireshark or other tools that sniff the traffic. Doing a post via ajax is a bad idea because it is too easy to use cross-site scripting to mess with the ajax call.

Daniel