Hi,
I was reading a few articles about secure login systems without SSL, as it looks a bit difficult to set up a server to accept HTTPS connections, create a certificate etc.
Anyway, the main problem would normally be that when a user logs in, the password is sent to the server as plain text, making it easy for other people to intercept that password. I found some 'solutions' on the internet that suggested encrypting (or, more specifically, hashing) the password with JavaScript before submitting the form. That would make the password unreadable for whoever is intercepting your internet traffic. Still, the author said that the system was still vulnerable to a 'replay attack', where the intercepted message is duplicated and sent to the server again, making it look as if the user logs in.
In order to fix this, a randomly generated key for challenge-response was suggested, so that every login-action is unique, and can't be used twice. This all made sense to me, and it appeared to me that this might work very well.
Until the point where a session variable is used to indicate that the user is logged in, where the session ID is connected to an ID that is stored in a cookie on the user's computer, which will be sent as plain text, making it very easy to just hijack the session, so the whole challenge-response system would be completely useless.
That brings me to my question: Is there any way to confirm that the user is really logged in? Or even: How bad is it to send a password as plain text (over a regular HTTP connection) to the server? I can imagine the things that can happen when someone intercepts the internet traffic of a certain user, but I've no idea how easy it is to do this. How likely is it that someone can get your password when sending it unencrypted over the internet?
