1. Introduction: Passwords Are the Last Line of Defense in the Digital World

In the entire ecosystem of internet security, passwords are the most common yet also the most fragile component. Almost all services we use daily—email, online banking, social platforms, games, forums—rely on passwords to authenticate user identity.

A password is essentially a weak credential:

• It cannot prove who the user really is—it only proves that they “know a certain secret.”
• Once this secret is leaked, an attacker can completely impersonate you.

Modern cyberattacks are frequent and diverse. A single ordinary password leak often results in multiple accounts across different platforms being compromised. To defend against these threats, we must strengthen both the transmission stage and the storage stage.

This article builds from fundamental concepts and gradually develops a complete, modern password security system.

2. Why Are Passwords So Dangerous?

At first glance, a password is just a string composed of characters. But the damage caused by a leaked password is far more severe than it seems, mainly for two reasons.

2.1 Risk 1: Leakage During Transmission

From the moment a user enters a password until it reaches the server, the data passes through:

• The browser
• Local DNS resolution
• OS network stack
• Routers
• ISP backbone
• Server load balancers

If any part of this chain is compromised, the password could be intercepted.

In theory, HTTPS solves the “eavesdropping problem.” But reality is more complex. Common risks include:

• Malware installing fake root certificates (classic MITM strategy)
• Internal corporate/school networks performing TLS inspection
• Public Wi-Fi conducting ARP spoofing and re-signing HTTPS certificates
• Browser extensions injecting malicious scripts to read user input
• “Network optimization” software adding hidden interception modules
• Enterprise gateways performing SSL inspection (legal but unsafe)

In other words:

You cannot assume the user’s device or network environment is always secure.

Therefore, there is room to improve the security of transmission.

2.2 Risk 2: Server-side Leakage

Most leaks occur on the server side. Common scenarios include:

• Database breaches (most common)
• Passwords accidentally printed in logs
• Developers outputting passwords during debugging
• Unencrypted backups mistakenly exposed to the public
• Third-party monitoring tools capturing sensitive fields
• Vulnerabilities (SQL injection, RCE) exposing the database
• Internal misuse of privileges by operations staff

If the server stores plaintext passwords, the consequences are catastrophic:

• All user passwords are exposed
• Accounts on other websites are compromised due to password reuse
• If attackers access a user’s email, the impact escalates further

Therefore, the server must ensure that even if a breach occurs, attackers cannot obtain the real passwords.

3. How Should Passwords Be Safely Transmitted Over the Internet?

3.1 The Most Straightforward Approach: Send the Password Directly Over HTTPS

This is the default method used by most websites today:

Browser ——HTTPS——> Server

Advantages:

• Simple
• Mature
• Fast
• Compatible with everything

The drawback is:

It places all risk on the reliability of TLS.

If TLS is compromised by a MITM attack, the password is exposed.

Thus, some propose hashing the password on the client side first.

4. Front-end Hashing: Risks Reduced and Risks Not Reduced

The core idea of front-end hashing is:

Even if the transmission is intercepted, the attacker does not get the real password.

Assume:

P  = user password
H1 = hash(P)

The browser sends H1 instead of P.

4.1 What Can Front-end Hashing Protect Against?

• Prevents MITM from obtaining the real password
• Prevents plaintext password leakage through server logs/monitoring
• Attackers cannot use H1 to log in to the user’s accounts on other websites
• Even if users reuse passwords elsewhere, a breach of your site won’t cascade to others (very important)
• The server never touches plaintext passwords (a simple form of zero-knowledge authentication)

Front-end hashing provides:

“Even if your website is compromised, attackers still cannot learn users’ real passwords for other services.”

Traditional approaches cannot offer this.

4.2 What Can Front-end Hashing Not Protect Against?

• Attackers can directly use H1 to log in to your website (you treat it as the credential)
• Keyloggers / infected devices still capture P
• Hashes without challenge are vulnerable to replay attacks
• HTTPS is still required—hashes themselves must be encrypted

In short:

Front-end hashing reduces damage but does not eliminate risk.

4.3 Is Front-end Hashing Necessary?

In practice, it is an optional but clearly beneficial enhancement.

When implemented properly (with challenges to prevent replay), front-end hashing creates a dual defense:

1. TLS ensures transport security
2. Hashing reduces cross-site password reuse impact

High-security systems (banks, enterprise platforms, developer services) often use such mechanisms.

5. How Should Servers Store Passwords?

Now to the core of password engineering:

Passwords must never appear in plaintext—even inside the server.

Industry standards involve three key elements:

1. Hash
2. Salt
3. Slow hash

5.1 Hashing: Making It Irreversible

A good hashing function must:

• Have extremely low collision probability
• Change output drastically when input changes slightly (avalanche effect)
• Make it impossible to reverse the input

Servers store:

H = hash(P)

If the database leaks, attackers cannot directly obtain the password.

5.2 Salt: Preventing Rainbow Tables and Mass Cracking

Without salt, users with the same weak passwords produce identical hashes. Attackers can:

• Use precomputed rainbow tables
• Test common passwords once to crack many accounts

By adding a random salt:

H = hash(P + salt)

Now:

• Two users with “123456” have completely different hashes
• Rainbow tables become useless
• Attackers must brute-force each user individually (massively increasing cost)

Salt must be:

• Long enough (≥16 bytes)
• Random (CSPRNG)
• Unique per user
• Stored in plaintext (not encrypted)

5.3 Slow Hashing: Truly Increasing the Cost of Attacks

Algorithms like SHA256 are far too fast. Modern GPUs can compute billions of SHA256 hashes per second.

Meaning:

Even with salt, SHA256-stored passwords can often be cracked quickly.

Thus, we must use slow hashing algorithms designed specifically for password storage:

Slow hashing is not about “stronger hashing”; it’s about:

Making each guess expensive so attackers cannot perform massive brute-force attacks.

Login delays are negligible:

• Users log in infrequently
• Each slow-hash costs only tens of milliseconds
• Attackers cannot scale up computations the same way

6. Dual Protection: Front-end Hash + Back-end Slow Hash

Combined:

P → H1 = hash1(P) → (transmission) → H2 = bcrypt(H1 + salt)

Dual-layer benefits:

1. MITM capturing H1 cannot use it on other sites
2. Database leaks revealing H2 are still hard to crack
3. Server never touches plaintext passwords
4. Logs and monitoring systems cannot leak P

This “front-end hash + back-end slow hash” model is used in high-security environments to reduce cascade risks.

7. The Replay Attack Problem of Front-end Hashing and Its Solution

If front-end hashing is simply:

H1 = hash(P)

An attacker who intercepts H1 can replay it indefinitely—almost identical to stealing the real password.

Solution: Use a random challenge.

7.1 Complete Workflow

1. User opens login page The server generates a challenge:

   challenge = random string
   

2. Browser computes:

   H1 = hash(P + challenge)
   

3. Server verifies:

   bcrypt(H1 + salt) == stored_hash
   

7.2 Benefits

• H1 is different every time (challenge varies)
• Intercepted H1 cannot be reused
• MITM value decreases
• Server does not need to store challenge—just verify once and discard

7.3 Common Engineering Issues

• Challenge must not be cached (use no-cache)
• Must be long enough (≥16 bytes)
• Front-end must use secure hash (SHA256 or higher)
• Still requires HTTPS (challenge itself can be intercepted otherwise)

8. Additional Important Practices (Often Overlooked)

8.1 Never Email Users Their Passwords

Sending a new password via email is extremely dangerous. Correct process:

• Send a password reset link
• Link contains a one-time token
• User must set a new password

8.2 Do Not Allow Weak Passwords

Weak passwords are exponentially easier to crack:

• 123456
• password
• qwerty
• User phone numbers
• User birthdays

Use:

• Blacklists of common passwords (top 10k)
• Length policies (≥12 chars)
• Encouragement of password managers

8.3 Multi-factor Authentication (MFA / 2FA)

Passwords are only the first layer. A second factor dramatically reduces attack success rates:

• TOTP (Google Authenticator)
• SMS codes (weaker, but still useful)
• Hardware keys (FIDO2 / U2F)

8.4 Account Protection Features

• Lockouts after multiple failed attempts
• Suspicious-login email alerts
• Unusual IP/UA verification steps
• Recent login activity logs for user review

8.5 Password Breach Checks (HIBP API)

Many large websites check whether:

• A user’s chosen password appears in known breach databases (like HaveIBeenPwned)

This significantly reduces risk from weak password reuse.

9. Goals of a Modern Password Security System

With all steps combined, a modern password system should ensure:

9.1 Secure Transmission

• Use HTTPS
• Optional front-end hashing to prevent cascading leaks
• Challenge-based anti-replay

9.2 Secure Storage

• Never store plaintext passwords
• Unique salt per user
• Use slow hashing algorithms

9.3 Account Protection

• Strong password policies
• MFA
• Anomaly detection
• Password leak comparison
• No sensitive info in logs

The final objective:

Even if the entire server is compromised, attackers still cannot obtain any user’s real password.