Home/ Questions/Q 8333843
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T03:09:29+00:00

I’m currently using a free host that doesn’t allow https connections, and since my

  • 0

I’m currently using a free host that doesn’t allow https connections, and since my site doesn’t host any sensitive or private content it’s not something I’d upgrade to paid hosting just to have. But since my site does handle passwords, and since many users use the same password for different sites, I would like to put a reasonable amount of security/encryption in the handling of those passwords.

From Secure login: public key encryption in PHP and Javascript, it looks like the biggest problem in using public/private encryption of the password to protect it when it’s sent over the network would be that an attacker could modify the public key sent to the client, and then intercept the encrypted password, decrypt it with the attacker’s private key, then encrypt it with the site’s public key, and then send it to the site, in essence defeating the whole point of encrypting it in the first place.

Of course, any encryption is better than no encryption, but I would like to do the best I can without having to purchase HTTPS-enabled hosting, which brings me to my question.

Is there any reliable way to prevent (or just detect & alert the user) a middleman from replacing their own public key in place of my site’s public key? Or is there any way to verify that the public key sent by the server is really the server’s public key? If there’s no way to verify this, how does SSL/TLS work, and how do they verify the keys (apologies if SSL doesn’t use public/private keys, I do have a pretty limited understanding of it)?

I already understand that just encrypting form data is an extremely weak practice compared to using TLS/SSL, and won’t stop people who are determined to break the encryption from doing it, so please refrain from any “you should be using HTTPS”-only comments (though if you know a free hosting provider that allows HTTPS, I’d be more than happy too hear about them)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The reason why SSL works is that the root certificates are distributed within the browser. There are many problems with this scheme, but in general you have a chain of trust – in this case ending with the trust on the browser (certificate store, distribution, installation etc.). It falls down when any Certificate Authority private key is insecure and this is currently a highly debated issue.

    Chain of trust:

    enter image description here

    Browsers certificate store:

    enter image description here

    The problem with JavaScript is that you don’t have (access to) a trust store, so there is no way you can trust the key you receive. The attacker could simply replace it with his own key (and login to your own site with his key). That would constitute a classic man in the middle attack, and there is preciously little you can do against it.

    Encrypting with the public key does give you some protection against eavesdropping attacks. Unfortunately, most attacks that have access to the connection in the first place are probably able to create a MITM, e.g. when using WiFi access points.

    Try and find your browsers trust store, you can probably view the configured root certificates distributed within it. This tree structure of certificates and private key is called Public Key Infrastructure (so Google it).

    • 0