How to securely send a password via HTTP using Javascript in the absence of HTTPS?

Question

The most basic problem that all developers face is that whenever a user submits a form, the password is sent through the network and it must be protected. The site I'm developing does not have HTTPS. The owner does not want to buy an SSL certificate, and he is not interested in self-signed. Therefore, I want to protect the password sent via HTTP using Javascript when submitting the form.

Waiting for downvoters: How to securely send a password through HTTP? DOES NOT give a reasonable solution, and I'm in a different situation.

If I use MD5, you can cancel this password line. What about nonce / hmac? Any javascript library available for this? Or do you have any suggestions / tips? Thanks in advance!

Answer 1

It is not possible to send a secure password that the user can verify without SSL.

Of course, you can write JavaScript that will make the password secure for pass-through through hashing or public key encryption. But how can a user make sure that JavaScript itself was not tampered with by a person in the middle before reaching it, to send a password to an attacker, not a site, or even just compromise the security algorithm? The only way is to be expert programmers and check every line of your page and script to make sure it is kosher before entering the password. This is not a realistic scenario.

If you want passwords to be safe from man-in-the-middle attacks, you must buy an SSL certificate. There is no other way. Get used to it.

If I use MD5, you can cancel this password line.

No ... not trivial, at least. While MD5 has attacks against it, it is a hashing algorithm and therefore is irreversible. You would have to copy it.

But then again, the man in the middle attacker does not need to look at your MD5. It can simply sabotage the JavaScript you send to the user to make MD5.

Answer 2

The solution here is to not send a password at all. Use call / answer.

In the original form, a large block of random text is included along with the key. Store the source random text in a key-based session on the server. When the client submits the form, use JS to share random text and password. Then send username, key and hash random text to the server. DO NOT send password. On the server, use the key to search for the source random text, perform the same hashing operation with the saved password. If the hash value of the server matches the hashed value of the client, then you know that the client entered the correct password without even sending the password to the server.

Whether the password is correct or not, the key and random text expire, so each of them is one-time.

Answer 3

If you really want to delve deeply into this, look at the Diffie-Hellman key exchange , which was created to "allow two parties that do not have each other's prior knowledge of jointly creating a shared secret key over an insecure communication channel"

I am not a specialist in cryptography, so I don’t quite understand if it is really safe if the attacker has both a client (JavaScript source code) and a transport mechanism (Packet sniffer)

Answer 4

Unfortunately, it will not be possible to ensure the security of an unencrypted request. Anyone who has access to your javascript will just be able to redo it / interfere with it, and anyone with a packet sniffer will be able to watch unencrypted traffic. These two facts together mean:

No SSL? No security.

Answer 5

You can use the RSA javascript implementation to encrypt the password before sending. (Here is an RSA example in Javascript .)

But I believe that this and the use of the hash function will be vulnerable to repeated attacks . So be careful.

Answer 6

Any transmission that you have will be in a clear form; that is, without SSL, your critical information will be disclosed. It is worth discussing this issue with the site owner. In other words, it’s best to take the necessary steps to strengthen your data transfer, and SSL is one of the basic, cheap steps you can take.

Answer 7

I do not think that the problem here is in technology, but how do you explain the importance of SSL. Provide them with reliable reading material, I am sure there is a lot on the Internet.

Answer 8

The solution requires the client to encrypt the password using a secret encryption key known only to the client and server.

SSL accomplishes this by requiring the server and client web browser to have their own asymmetric public / private key pair, which they use to encrypt and transmit a random session key between them. The rest of the conversation uses this secure session key.

So, you are asking how to solve the same problem as SSL, without using a secret key that is known only to the client and server. I am not an expert, but it seems that this is impossible, or at least not easy.

Answer 9

If you do not have access to SSL, MD5 should be sufficient to prevent accidental discovery of passwords (for example, in a network log file or something else). Anything else would be a waste of time. Just make sure that the application does not provide access to confidential information (for example, credit card numbers, medical history, etc.).

Like other commentators, a serious attacker will be able to break any type of security on the page. Even SSL is a small barrier, as most users use easily verifiable passwords, reuse the same passwords all over the world, give their password to anyone who asks or can be tricked to refuse their password on the copied page or “tech support” .

Answer 10

- English - I think something, but I don’t know if it can really be safe. If you can put your form in a php file, you can create an algorithm to create a line based on time or something else, and then put that line in your html.

When a user enters a password in the password input field, when you debug it, you cannot see the value entered by the user, therefore, before sending information via a message or receiving, you can use the password user as a hint to encrypt the encrypted string generated earlier, and then simply sent the password entered by the user.

Thus, the attackers do not have js inside the code, so they will need to open the algorithm that you create in order to decrypt it.

This is just an idea, so if you can tell me how it cannot be safe, I would appreciate it.

- Spanish - Se me acaba de ocurrir algo que puede servir, pero no se si realmente sea algo seguro. Por medio de php puedes generar un algoritmo que cree un string en base al timestamp o algo más, y después colocar esta cadena en el html.

Note: cuando alguien escribe una contraseña en un campo input tipo password, con un debug no se puede ver el valor que tecleo el usuario (no se si exista manera pero no quise researchar más), asi que podemos utilizar la contraseña que el usuario escribió como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php, por medio de un algoritmo en JS. The series algo así como encriptar lo encriptado. For more information, please contact without comment. Tcleada, si no esta última cadena resultante.

Buscando un contra, lo único que se me ocurra es que el atacante tendrá que dedicarle mucho tiempo para tratar de encontrar el agoritmo que creamos por medio de php y poder decriptar la cadena final, o tendrá que hackear el servidor para acceder al php y obtener el algoritmo.

Esto es solo una idea, por lo que si pueden decirme como esto puede no ser seguro, se los agradecería.

Answer 11

As already mentioned, none of this is protected from server spoofing, as this requires the ability to trust client-side Javascript. But if we are sure that the server cannot be tampered with (a signed certificate, the hash signature is not protected from length, etc.), but not that the connection is immune to listening devices, this is how I implement it.

I think the safest way is instead of storing H (password), where H is your hash select function, keep g ^ H ( password ), i.e. use the password as a private key for Diffie-Hellman key exchange. (You should probably also use random g for different users - this becomes your salt.) Then, to check, you generate nonce b, send the user g ^ b and calculate (g ^ H ( password )) ^ b. The user does not need to know g - they only need to calculate (g ^ b) ^ H (password) = (g ^ H (password)) ^ b. Now you have a number that both parties know if the user enters the correct password, and building a test answer with zero knowledge based on knowing the correct number is trivial, and the random number used as the "private key" of the server makes it suitable for protection against repeated attacks.