How Frontend Slow Encryption Boosts Password Security and Defends Against Data Breaches

0x00 Preface

Fast algorithms are easy to break; slower hashing increases attack cost.

0x01 Brute‑Force

Password cracking ultimately relies on exhaustive search: try every possible password using the same hash algorithm as the target.

Even if a lookup table is used, the table must be generated by exhaustive enumeration.

Hash functions are one‑way; the only way to recover the original password is by guessing.

The speed of guessing matches the speed of hashing; e.g., MD5 can compute a hash in about 1 µs, allowing a million guesses per second on a single thread.

0x02 Slow Hashing

Increasing the time per hash directly raises cracking time; a 10 ms hash reduces guesses to 100 per second, a ten‑thousand‑fold slowdown.

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

for i = 0 ~ 10000
    x = md5(x)
end

Algorithms like bcrypt and PBKDF2 already provide configurable work factors.

0x03 Applications of Slow Hashing

Passwords stored in databases benefit most from slow hashing because leaked password hashes become much harder to crack.

Even if an attacker obtains the database, they must still brute‑force each slow hash, turning a quick crack into a months‑long effort.

0x04 Drawbacks of Slow Hashing

Slow hashes consume CPU cycles, potentially exhausting server resources under heavy load or malicious login attempts.

High‑traffic sites may need dedicated clusters to handle the extra computation.

0x05 Front‑End Encryption

Modern browsers have enough compute power to perform slow hashing on the client side, sending only the slow‑hash result to the server.

The server stores the received value exactly as it would a plain password.

If the database is leaked, attackers only obtain the slow‑hash, which still requires a full cracking effort.

Because the slow‑hash is a random‑looking 32‑character hexadecimal string, dictionary attacks are infeasible.

Even though the server cannot reverse the slow hash, it can verify passwords by re‑hashing the client‑side result.

back_fast_hash( front_slow_hash(password) )

This two‑stage approach dramatically slows down online password‑guessing attacks.

0x06 Countering Pre‑Computation

Since the front‑end algorithm is public, attackers could pre‑compute hashes for common passwords. Adding a per‑user salt (e.g., the username) makes each hash unique. front_slow_hash(password + username) Salts can be generated on the client and stored on the server.

# Front‑end generates salt
salt = rand()
password = front_slow_hash(password + salt)
submit(..., password, salt)

During login, the client retrieves the stored salt and repeats the same process.

0x07 Strength Strategies

Two approaches: fixed work factor for all users, or variable work factor based on client capability.

Fixed strength can offload unfinished work to the server if the client times out. [Front‑end] 70% done → [Back‑end] finish remaining 30% Variable strength lets each user’s device determine how many hash iterations it can perform within a target time, storing that step count as part of the account.

# Registration – benchmark
while (time < 1s) { x = hash(x); step++; }
# Login – repeat stored steps
for i = 0 ~ step { x = hash(x); }

Dynamic adjustment can lower the work factor on low‑end devices and raise it again on stronger hardware.

0x08 Performance Optimisation

Even though the goal is to be slow, unnecessary overhead should be avoided; using asm.js, WebAssembly, or compiled C/C++ (via Emscripten) can make the hash run efficiently.

Flash/ActionScript was historically used for similar purposes on older browsers.

0x09 Countering GPU Attacks

GPU‑friendly algorithms (e.g., scrypt) limit parallelism by heavy memory usage, making GPU attacks less effective.

Mixing multiple hash functions (as in X11Coin) also raises ASIC/GPU resistance.

0x0A Additional Benefits

Reduces risk of plaintext leakage because the password never leaves the browser.

Prevents servers from storing plaintext passwords.

Increases the cost for attackers attempting online credential stuffing, acting like a proof‑of‑work.

0x0B Limitations

Front‑end slow hashing does not protect against man‑in‑the‑middle attacks on non‑HTTPS connections; an attacker could still replay the slow‑hash.

If the attacker can inject malicious scripts, they can capture the plaintext before hashing, which is outside the scope of this article.

0x0C Multi‑Threaded Slow Hashing

Purely sequential hashes cannot be parallelised, but independent salted hashes can be computed in parallel and combined at the end.

# 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 results
final = hash(x1 + x2)

0x0D Summary

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

0xFF Postscript

Early experiments with browser‑based mining inspired the ideas presented here, combining classic cryptography with modern web technologies.