Why Simple HTML Login Forms Leak Passwords and How to Secure Them

1. A Simple HTML Example to Observe User Information Security

Standard HTML syntax supports using <form> tags to create an HTTP submission. A typical login form looks like:

<form action="http://localhost:8080/Application/login" method="POST">
    Username: <input id="username" name="username" type="text" />
    Password: <input id="password" name="password" type="password" />
    <button type="submit">Login</button>
</form>

The form submits the values of inputs that have a name attribute as parameters in the HTTP request body for login verification.

Even though the password field displays as dots, the request can be captured in plaintext using browser developer tools.

2. HTTP Protocol Directly Exposes User Password Fields

During network transmission, sniffing the HTTP traffic reveals sensitive information, as shown in captured packets.

3. Can Encryption Algorithms Ensure Password Security?

Frontend can encrypt the password before sending, using symmetric or asymmetric encryption.

Symmetric encryption: Uses the same key for encryption and decryption.

Asymmetric encryption: Uses a public key for encryption and a private key for decryption.

3.1 Using Symmetric Encryption

One simple method is to shift the string and reverse it:

123456 --> 456123
456123 --> 321654

This approach has two drawbacks:

Both frontend and backend must modify code simultaneously.

The encryption logic in JavaScript can be reverse‑engineered.

3.2 Is HTTPS Always Secure?

HTTPS relies on public‑key cryptography, but it is still vulnerable to:

Capture of ciphertext on client or server side.

Man‑in‑the‑middle attacks if a malicious certificate is installed.

4. Conclusion: Passwords Must Be Transmitted as Ciphertext

Even with HTTPS, it is advisable to hash passwords on the client side, e.g., using MD5, before transmission. Benefits include protecting stored passwords, preventing plaintext exposure during transmission, and ease of implementation.

Ensures database password safety.

Prevents attackers from recovering the original password from intercepted data.

Simple, efficient, and widely supported.

5. Can This Replace HTTPS?

Even with client‑side MD5, attackers can replay the hashed password to log in.

5.1 Solution 1: Captcha

Use server‑generated captcha images stored in session to verify human users.

5.2 Solution 2: Token

Generate a random token (e.g., UUID) per login, store it in Redis, and require the client to send it back. The token is deleted after successful authentication, preventing replay attacks.

6. Beware of Data Tampering

Even with encrypted passwords and tokens, an attacker can modify other request fields such as the amount in a payment transaction.

6.1 What Is a Digital Digest?

A digital digest (hash) produces a fixed‑length fingerprint of data, ensuring integrity.

6.2 Digital Signature

The sender hashes the message, encrypts the hash with its private key, and sends both the message and signature. The receiver hashes the received message and decrypts the signature with the sender’s public key; matching hashes confirm authenticity and integrity.

Applying this to login, the client can sign username + MD5(password) + token to produce a checkCode that the server verifies.

7. Summary

Simple web login forms contain many security risks. The article outlines various mitigation strategies, including client‑side hashing, token authentication, captchas, and digital signatures, while acknowledging their limitations.

Supplement 1: JS Encryption Can Be Cracked

JavaScript encryption logic can be reverse‑engineered, so dynamic loading of encryption strategies from the server is recommended.

Supplement 2: MD5 Vulnerabilities

MD5 is considered weak; collisions allow attackers to find different inputs that produce the same hash, so stronger algorithms like bcrypt or PBKDF2 are preferred.