undefined | Better HN

0 pointschowells4y ago0 comments

Your analysis seems to overlook an important detail in that first bullet point - dictionary attacks are only feasible when the KDF is fast. Authentication servers tend to require the KDF to be fast so they aren't constantly performing a denial of service attack on themselves. What people are looking for is a way to make the combined KDF slow by pushing most of the work to the client side. If this succeeds, you have made dictionary attacks very difficult without making your authentication process a denial of service vector.

The web browser ecosystem makes this a pretty hard task, unfortunately. You need fallbacks that weaken the process to the point where it is basically useless in a lot of cases. But the goal of a client/server split in the KDF is actually quite sensible. The client side does the large amount of work to protect users from dictionary attacks. The server side does a relatively much smaller amount of work to protect itself from being easily exploited if its hashes are exfiltrated when the hashes aren't themselves vulnerable to dictionary attacks.

0 comments

chrisfosterelli4y ago

This is an interesting point. I'd be inclined to ensure that the server side hash is still at least independently expensive enough as would be desirable for plain text, but then using the client side hash to go above and beyond computationally seems reasonable to me.

I would wonder though -- there's obviously a practical limit on user experience for waiting for computation, and is there really fast enough implementations available to the browser within that limit that would foil what a dedicated attacker could compute in proper hardware for a dictionary attack? You'd also have to consider if it's really that expensive to just throw more hardware at a server side hash. I guess it'd depend on the browser, whether the attack is targeted, and how big the attacker's budget is that you're considering.

Either way, if this was the goal and the team considered those factors then still felt it was worth the effort of doing so I would think it seems reasonable, though it's probably not something I'd make standard practice in my own apps.

Strom4y ago

> is there really fast enough implementations available to the browser

Browsers have pretty good support for surfacing native code SHA family hash functions which you can use to speed up PBKDF2. It's called the Web Crypto API and it's available even in Internet Explorer 11. [1]

If you're willing to drop support for IE11 and 10+ year old phones like the iPhone 4S, then you get access to WebAssembly. With WASM you can get a bunch of custom algorithms to be quite fast. The Argon2 browser WASM library claims to be only about 10x slower than optimized native code. [2]

It's not perfect, but it isn't as bad as it used to be with just pure JavaScript.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...

[2] https://github.com/antelle/argon2-browser

chowellsOP4y ago

Yeah, I can't really justify using this in browsers because their capabilities vary so widely. Logging in shouldn't take 10 minutes on a 5-year-old feature phone.

But I can see using a split KDF for some high-security system where the clients all have a known minimum spec.

mafuy4y ago

> that the server side hash is still at least independently expensive enough

That is useless if a hash of the passphrase is sent by the client. The input space is evenly distributed over all hash values, so a dictionary attack is no better than sending all possible hashes directly (brute force).

A single round of server side hash suffices here.

j / k navigate · click thread line to collapse