@brimstoneSalad, what do you think is the reason it's considered bad to have just one part of your website served over HTTPS (passwords, for example), while having other parts served over HTTP? As far as I understand, it's primarily to prevent this form of attack:
First, the hacker intercepts all the HTTP pages (which is trivial) and modifies the "login" link to point to some page he has made. Or, it intercepts the GET requests referring to the log-in page and responds to them with the "redirect" command (also not hard to do). Second, the hacker's log-in page is an HTTPS page, modified to include some script from the hacker's server (to suppress the browser cross-scripting-attack-defense), and to do an AJAX to the hacker's server revealing the password, along with POST-ing the password to the original website.
So, indeed, serving only a part of the web-site with passwords in HTTPS is better than nothing (it prevents the hacker from merely intercepting all connections to a server and extrapolating the passwords with regular expressions), but it's much better to serve a whole website, which requires passwords, over HTTPS. It might be counter-productive since it's lulling people into false sense of security.
I mean, to be honest, I am not really the biggest expert in this part of informatics. I wouldn't know how to implement, for example, the RSA algorithm or the elliptic-curve cryptography myself. My
website requires a password to reset the back-end of the on-line compiler (to prevent the denial-of-service-attack by somebody resetting the back-end again and again). To protect my password from being intercepted, I implemented the following easy-to-implement algorithm (you can see the code
here, it's from the 1507th to the 1548th line):
1) The browser sends a randomly-generated one-byte session-key to the server and requests (using AJAX) a two-byte one-time key.
2) The server sends that key plus 257 times the session-key to the browser.
3) The browser sends, using JSON, the password encrypted with the received the one-time two-byte key using the XOR cypher.
4) The server, knowing the one-time two-byte key, deciphers the password, hashes it, and compares the hash to the hash stored on it. Then it informs the browser if the password is right and acts accordingly.
The obvious problem here is that the XOR cypher is symmetric, so the hacker that intercepts the connection three times (both when the session key is communicated, when the key is communicated, and when the password is communicated) has all the knowledge needed to decode the password. I just relied on the hacker not being willing to study my algorithm in order to get my password. An attempt to extrapolate my password by intercepting the connections and using the regular expressions will fail, and the hacker will probably give up.
One recommendation I've seen on-line is that the client shouldn't perhaps attempt to send the encrypted password, but only its hash, hashed using the one-time key given to it by the server. However, in order to implement that, I need to reveal the password to the web-hosting service I use, and they really aren't to be trusted.