Password Transmission over the Internet: Which is Safer - Hashing or TLS?

I thought about this article a year ago when professors from my institute started asking me questions about the "secure" transmission of passwords, but I only got around to it now.

The essence of the dilemma lies in the misunderstanding of server certification and secure networks both by the professors and myself. When creating websites, I by default install SSL certificates to domains, configure their auto-renewal, redirect from HTTP to HTTPS, and forget about them. My main task becomes writing a server with protection against various vulnerabilities.

According to the logic of the professors, my project on the client side should hash the password and send it to the server, where it will be compared to the already stored hash. However, an obvious question arises: "Why can't an attacker intercept the hash and use it for authentication?" The professors couldn't give a clear answer, claiming that it's "safer" this way. In fact, this scheme contradicts the very concept of security: a readable password is simply replaced with a hash, which becomes vulnerable to a Pass-the-Hash attack. I insisted on the importance of SSL certificates and the use of TLS protocols.

How does cryptography work on the internet?

Many have noticed that browsers sometimes warn about an insecure connection to websites with HTTPS.

This means that the certificate is either self-signed (which does not guarantee its security) or issued by a certification authority that the browser does not trust.

What is an SSL certificate and why is HTTPS needed?

The letter "S" in "HTTPS" means that the website uses an SSL certificate. The certificate contains:

• Private and public keys;

• Issue date and expiration date;

• Who it was issued to and by whom.

The public key is necessary to establish a secure connection. This technology is based on asymmetric encryption, where a pair of keys is used:

• Public key (can be shown to everyone);

• Private key (kept secret).

These keys are mathematically linked in such a way that data encrypted with one of them can only be decrypted by the other.

Thus, the client uses the server's public key to encrypt data, and the server decrypts it with its private key. Even if an attacker intercepts the encrypted data, they will not be able to decrypt it without the private key.

Diffie–Hellman Algorithm: Explanation with Paint Example

Next, the Diffie–Hellman algorithm comes into play. It allows two parties to create a common secret key even in the presence of an observer.

How does it work?

1. The client and server agree on a common "color" (public number).

2. Each side adds their own secret "color" (secret number) and sends the modified value.

3. As a result, both sides obtain a common "secret color" (key), but an attacker observing the process cannot compute it.

MITM attack and protection against it

One of the main risks when transmitting data is a "man-in-the-middle" (MITM) attack. In such an attack, an attacker substitutes the server's public key with their own and intercepts the encrypted data.

How TLS protects:

• Using certificates from trusted certificate authorities (CAs) prevents key substitution.

• The HSTS (HTTP Strict Transport Security) protocol prohibits the use of HTTP, forcing HTTPS to be activated.

• Modern browsers check the digital signature of the certificate and warn the user about security issues.

Checking connection security with Wireshark

To ensure that the data is transmitted in an encrypted form, I used Wireshark.

To filter the necessary packets: ip.host == 81.90.182.13, where 81.90.182.13 is the IP address of the server of my project.

The screenshot shows several lines with information about the connection:

• "Client Hello" – initiation of the TLS connection;

• "Server Hello" – server's confirmation and selection of the encryption algorithm;

• "Change Cipher Spec" – exchange of session keys;

• "Application Data" – encrypted GET and POST requests.

GET data:

The data from the screenshots shows that the data sent by the client is completely encrypted. For clarity, one can also look at the unencrypted packet of data that I sent while testing the TCP protocol in C#.

Unencrypted data:

From this screenshot, one can easily read the transmitted set of data. In the first case, the data was also transmitted in Latin, which would not make it difficult to read through this program.

Why client-side hashing is a bad idea?

Hashing passwords on the client side does not protect against Pass-the-Hash attacks, where an attacker intercepts the transmitted hash and uses it to log in. Unlike a password, the server cannot distinguish between a compromised hash and the original one.

Simple approach:

1. The password is transmitted in an encrypted form via HTTPS.

2. The server hashes it with salt (bcrypt, Argon2, PBKDF2).

3. The stored hashes cannot be used directly for authentication.

Situation: An attacker simulates data transmission

If an attacker fully simulates data transmission by forging requests, security is not guaranteed. In such cases, it is necessary to use protection mechanisms such as temporary tokens (nonce) or two-factor authentication mechanisms.

Situation: An attacker has obtained the encryption key

If an attacker manages to obtain the encryption key, they will be able to decrypt the transmitted data. To protect against this, salt can be used.

Example of a salt protection mechanism:

1. The server sends the user a random salt before authentication.

2. The user hashes their password, as the server does.

3. Then they add the obtained salt to the hash and hash it again.

4. They send the resulting value to the server.

5. The server performs the same operation on its stored hash and compares the results.

This mechanism protects against leaks, as intercepted data is useless without the dynamic salt.

Conclusion

As shown, transmitting the password over HTTPS is indeed secure, as the data is encrypted and not available for interception.

Unlike client-side hashing, which does not protect against the "Pass-the-Hash" attack, SSL/TLS provides: Confidentiality (intercepted data is useless without the key); Integrity (protection from data tampering); Authentication (server authenticity verification).

If the project requires secure password transmission, there is no need to hash it on the client – use SSL/TLS, encrypt the data, and store passwords with hashing on the server.

Personally, in my project, I transmit the plain password over secure networks, comparing it with the hash on the server, and always initialize 2FA authentication, which prevents access to intruders, even if they have obtained the original password.