question about ssl

[uberalles]

I've noticed on Facebook that when you log in the page itself is not a secure socket but then it redirects to a secure page and logs in from there. Does anyone know how that works? Aren't they exposed when going from the non-secure login page to the https page?
Thanks in advance.

[Stephen Philbin]

It's important to remember that encryted connections only protect data whilst it is being moved from one end of the connection, to the other. Because of this, it's utterly pointeless encryping the page that only contains the login form. The thing part of the process that needs to be protected is the form submission because that's when the login data actually gets transferred over the line.

The thing that puzzles me is the behaviour of some sites after the login process has been completed. Either there's some pretty significant part of the puzzle that I'm missing (very possible) or some sites are completely negating the security provided by logins made over secure lines. I've seen quite a few sites require that you log in over a secure line, but once you are logged in, you then move back to connecting over non-secured lines and you are once again left completely exposed.

As far as I know, once you are logged in, you must identify yourself to the web server on every single page request. So on sites that have you log in over a secure connection, but have you browse the rest of the site over non-secured lines seem completely insecure to me. As far as I can tell, the password is protected from being sniffed out but then the session data is left wide open so that an attacker wouldn't need a password anyway (and so obviously negate the password protection).

If anyone's got any insight into how a session can be secured over an non-secured line, I'd love to hear it.

[uberalles]

That does concern me. I have one site that requires a secure login, where a session is created but I use a session check on every page afterwards. If the password is not contained in the stored data session, is that considered secure?

[ray326]

It's important to distinguish the difference between session data and request data. The only thing potentially visible on the network is request data. Session data is in the memory of the app server unless it's serialized in the response via cookies or in the page in the form of hidden fields, both of which are very bad practice from a security standpoint.

Anyway, for a form-based login you need an unprotected form (i.e. doesn't require authentication) which posts to a handler that creates the session, after which the rest of the site should be protected. Note that SSL has nothing to do with authentication and vise versa. The whole conversation should be encrypted whether it's authenticated or not.

[Stephen Philbin]

I know that the data stored in the session is not transmitted and stays on the server side, but isn't the session identifier still transmitted in the conversation so that the server knows which login they are dealing with?

How else would the server be able to keep track of who is who without a session identifier being sent from each client? The only thing I can think of is the IP address, but wouldn't that be unreliable? Don't some ISPs (AOL?) keep changing the IP addresses of customers whilst they are surfing?

[uberalles]

Right....I believe a session id is stored as a cookie (or appended to the url) but the data itself is stored on the server end.
Is it possible that Facebook uses some sort of javascript to store the information on the client (cookie) and then transmit the data when it switches to the secure page?

[Stephen Philbin]

Right....I believe a session id is stored as a cookie (or appended to the url) but the data itself is stored on the server end.
Indeed it is. Ot at least that's the only reliable mechanism I know of.
Is it possible that Facebook uses some sort of javascript to store the information on the client (cookie) and then transmit the data when it switches to the secure page?
I would think it's certainly possible, but it's definitely not a method I would use. It would leave the door wide open for allowing people to screw around with your system.

[ray326]

I know that the data stored in the session is not transmitted and stays on the server side, but isn't the session identifier still transmitted in the conversation so that the server knows which login they are dealing with?Yes. The key to the session data has to either be in a cookie or in the query string. And either way it's in plain text so encrypting the conversation with SSL is a good idea to help prevent session spoofing.

Does the Facebook login form post to http or https? If the former then they're as stupid as some of the security hacks against them would indicate.