3 ms·

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 pla

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.

chowells 5y 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.
Strom 5y 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_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... [2] https://github.com/antelle/argon2-browser https://github.com/antelle/argon2-browser
mafuy 5y 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.

chowells 5y 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.

Strom 5y 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_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... [2] https://github.com/antelle/argon2-browser https://github.com/antelle/argon2-browser

mafuy 5y 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.