Why Simple Web Login Is Vulnerable and How to Secure It with Encryption and Tokens

1. Simple HTML Example of User Information Security

Standard HTML form using <input> tags for username and password, submitted via POST to "Application/login".

<form action="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 sends the values of inputs with a name attribute as HTTP body parameters for backend validation.

Even though the password field is masked, the request can be captured in clear text.

2. HTTP Transmission Directly Exposes Password Field

Sniffing tools like Fiddler or Wireshark can capture the password in plain text.

3. Can Encryption Algorithms Guarantee Password Safety?

Front‑end 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 Symmetric Encryption Example

Simple example: shift the string then reverse it.

123456 --> 456123
456123 --> 321654

Drawbacks: both front‑end and back‑end must be changed, and JavaScript code can be reverse‑engineered.

3.2 Asymmetric Encryption (HTTPS) – Is It Always Safe?

HTTPS protects transport but does not prevent man‑in‑the‑middle attacks on the client or server side, nor does it protect against replay attacks if the token is missing.

4. Conclusion: Password Must Be Transmitted as Ciphertext

Even with HTTPS, additional application‑level protection such as hashing the password (e.g., MD5) before transmission is recommended.

5. Can We Skip HTTPS by Using MD5?

MD5 hashing of the password before sending prevents the clear‑text password from being exposed, but attackers can still replay the hashed value to log in.

5.1 Solution 1: Captcha

Server generates a captcha image and stores the value in the session for later verification.

5.2 Solution 2: Token

In a front‑end/back‑end separated architecture, after successful login the server issues a random token (e.g., UUID) stored in Redis; the client must include this token in subsequent requests.

6. Data Tampering Risks

Even with encrypted password and token, an attacker can modify other fields (e.g., amount) in the request. Digital signatures using a hash of the data signed with a private key can detect such tampering.

6.1 What Is a Digital Digest?

A hash function produces a fixed‑length fingerprint of the original data; identical inputs yield identical digests.

6.2 Digital Signature

The sender hashes the message, encrypts the digest with its private key, and the receiver verifies it using the sender’s public key.

7. Summary

Web login appears simple but contains many security pitfalls; proper encryption, token, captcha, and digital signatures are needed to protect credentials and data integrity.

Supplement 1: JS Encryption Can Be Cracked

If attackers read the front‑end JavaScript, they can replicate the encryption algorithm.

Supplement 2: MD5 Weaknesses

MD5 is vulnerable to collisions; stronger algorithms such as bcrypt or PBKDF2 should be used.