The problem: I’m building a forum with a custom engine and I don’t want the expensive Argon2 function to be computed server-side (DDoS risk). Instead, it should be computed client-side in JavaScript — but crucially, the server should then run the result through a single fast SHA hash before storing or comparing it.
Let’s look at the attacks:
SHA hash leak — Argon2 still has to be computed (e.g. a million times) regardless of whether the protection runs client-side or server-side.
Man-in-the-middle — the hash can always be intercepted, whether I’m sending plaintext or an Argon2 digest, so here I simply have to assume a secure transport layer — HTTPS, not HTTP.
Apart from the fact that my approach doesn’t put load on the server, I don’t see how it’s worse.
Claude agrees with me, while GPT insists Argon2 must run server-side. Maybe I’m just hearing what I want to hear — but Claude’s reasoning resonates with me, whereas GPT feels like someone who crammed the textbook without understanding it.Addendum / Reply to the obvious objection:
Yes, a determined attacker could skip the client-side Argon2 and send a raw SHA directly — but that completely misses the point. The threat model here is DDoS, not account takeover. In a DDoS scenario, the attacker is flooding the server with requests hoping to exhaust its CPU with expensive Argon2 computations. If the client sends a raw SHA instead of a proper Argon2 hash — they simply won’t log in. The server just does one cheap SHA and compares. No expensive computation happens server-side at all.
So:
Legitimate user → runs Argon2 client-side → sends result → server does 1× SHA → matches → login OK
DDoS bot → skips Argon2, sends garbage → server does 1× SHA → no match → login fails → server spent almost nothing
The attacker gains nothing by bypassing Argon2 except a failed login at negligible server cost. That’s the entire point. The expensive computation either happens on their machine or not at all.in Polish (part of discussion, GPT side): https://chatgpt.com/share/69cbbbf6-854c-8396-8b4e-c08029d7deb3