Can Frontend Slow Encryption Really Strengthen Password Security?

0x00 Preface

All martial arts rely on speed, but password hashing is the opposite: the faster the algorithm, the easier it is to break.

0x01 Brute‑Force Attack

Password cracking means restoring the original password from its hash. Ultimately, every method ends with exhaustive enumeration.

Even if you use a lookup table, the table itself must be generated by exhaustive enumeration, so the fundamental principle remains the same.

Hash functions are one‑way and irreversible, so the only way to recover a password is by trying possible inputs until a hash matches.

The speed of enumeration depends on the hash algorithm; if hashing takes 1 µs, each guess also takes 1 µs, allowing millions of guesses per second on a single thread.

0x02 Slow Hashing

Increasing the time required for a single hash directly increases the time needed for an attacker to try each guess.

If hashing takes 10 ms instead of 1 µs, an attacker can only try about 100 passwords per second—a ten‑thousand‑fold slowdown.

The simplest way to slow hashing is to repeat the hash many times.

function slow_md5(x) {
  for (let i = 0; i < 10000; i++) {
    x = md5(x);
  }
  return x;
}

Attackers must run the same repeated hashing when they try passwords, so the cracking time grows proportionally.

Well‑known slow‑hash algorithms such as bcrypt and PBKDF2 already use a configurable work factor to control the duration.

0x03 Applications of Slow Hashing

The most critical place to use slow hashing is for storing user passwords in a website’s database.

Many recent data‑leak incidents expose plaintext passwords because sites used fast hash functions, making weak passwords trivial to crack.

By increasing the hash time by 100×, cracking a password can take months instead of seconds, protecting the last line of user privacy even if the database is stolen.

0x04 Drawbacks of Slow Hashing

Slow hashing consumes significant CPU resources; a busy server may run out of capacity when many users log in simultaneously.

Malicious users could launch massive login attempts to exhaust server resources.

Therefore, extremely high work factors are rarely used in practice.

0x05 Front‑End Encryption

Modern client devices are powerful enough to share part of the hashing workload.

Instead of sending a plaintext password, the client can send the result of a slow hash.

The server stores this value exactly as before, so no server‑side changes are required.

If the database is leaked, attackers only obtain the slow‑hash result, which still requires another cracking step to recover the original password.

The slow‑hash result is a random‑looking hash (e.g., a 32‑character hexadecimal string) that cannot be reversed by dictionary attacks because the space is astronomically large (16^32 possibilities). back_fast_hash(front_slow_hash(password)) During login, the client computes the front‑slow hash, the server applies its fast hash, and the two hashes are compared.

0x06 Countering Pre‑Computation

Since the front‑slow algorithm is public, attackers could pre‑compute a dictionary of slow‑hash results.

Adding a salt mitigates this; a simple approach is to use the username as salt: front_slow_hash(password + username) Although the username is public, it still forces attackers to build a separate dictionary for each user.

Ideally, a random salt generated on the client is sent together with the hash and stored on the server.

0x07 Strength Strategies

Users have heterogeneous hardware; a fixed work factor may be too slow for low‑end devices.

Two approaches are possible:

Fixed strength for all users.

Variable strength based on the device’s capability.

1. Fixed Strength

Choose a moderate work factor that most users can handle; if a client cannot finish, it sends the partially computed hash to the server to finish the remaining work.

[Front‑end] 70% done → [Back‑end] finish remaining 30%

2. Variable Strength

During registration, the client runs the hash repeatedly for a short time (e.g., 1 second) and records how many iterations it can complete; this step count becomes the user’s strength parameter.

# Registration phase
while (time < 1s) { x = hash(x); steps++; }

During login, the client repeats the hash exactly the recorded number of steps.

# Login phase
for (i = 0; i < steps; i++) { x = hash(x); }

This lets powerful devices use higher strength while keeping the experience acceptable on weaker devices.

3. Dynamic Adjustment

If a user frequently logs in from a low‑end device, the client can automatically lower the work factor; when a high‑end device is used again, the factor can be raised.

4. Out‑of‑the‑Box Idea

For high‑traffic sites, the collective CPU of online users could be harnessed as a distributed computing pool to perform the heavy hashing work.

0x08 Performance Optimisation

1. Why Optimise?

Even though the goal is to make hashing slow, using inefficient code adds CPU overhead without increasing security.

2. Front‑End Bottlenecks

Web scripts are interpreted, weakly typed, and run in a sandbox, which introduces extra checks and slows down tight loops.

Technologies like asm.js or WebAssembly can provide near‑native performance for heavy hashing.

3. GPU Resistance

Algorithms that heavily depend on memory bandwidth (e.g., scrypt) limit GPU parallelism, while CPU‑friendly designs can include many conditional branches to hinder GPU acceleration.

0x09 Additional Benefits

Front‑end slow hashing reduces the risk of plaintext password leakage, because the password never leaves the client in clear form.

Even if the communication channel is compromised, only the slow‑hash result is exposed, which is infeasible to reverse.

It also raises the cost for credential‑stuffing attacks, acting like a lightweight proof‑of‑work.

0x0A Limitations

Front‑end slow hashing does not protect against compromised client machines or malicious scripts injected into the page.

If a site uses slow hashing without HTTPS, an attacker can still replay the slow‑hash result to hijack accounts, though the original password remains hidden.

0x0B Multi‑Threaded Slow Hashing

On multi‑core devices, the hash can be parallelised by hashing the password with different salts in separate threads and then combining the results.

# Thread 1
x1 = hash(password + "salt1")
for i = 0..2500 { x1 = hash(x1) }
# Thread 2
x2 = hash(password + "salt2")
for i = 0..2500 { x2 = hash(x2) }
... // combine and hash again

0x0C Summary

Front‑end slow encryption lets each user contribute a small amount of computation, making password storage harder to crack even if the database is leaked.

The collective computational effort of all users dramatically raises the cost of offline attacks.