4 ms·
but I'd think the point of a js KDF is to run on the client, not the server. bcrypt is used on the server (node.js) to hash a user's password before storing it
by dsp1234 11y ago
but I'd think the point of a js KDF is to run on the client, not the server.
bcrypt is used on the server (node.js) to hash a user's password before storing it in the database. Then later, when a login is done, the password from the login is checked against the stored hash to see if the match (and by implication, that the original passwords are the same). So the usage is mostly on the server as expecting a client such as a mobile device to do large rounds of CPU intensive work just to login isn't going to make for happy customers.
- novaleaf 11y agoright, but running bcrypt on a server, why run a pure javascript version? Why not the C-compiled version? So to me the logic behind a pure js version is one that can run on the client too. It actually sounds interesting, as it could improve password security! But it's just too slow. In my case, I ended up sha512'ing the password client-side, and use that as the "password" sent to the server. If there were a native KDF for all browser's i'd use that instead.
- Klathmon 11y agoIn our case, we use the pure-js version during development. Some windows developers have issues compiling native modules, and it was easier to try the native plugin, if it fails fallback to the pure-js version with an identical API during development. That way we get the ease of development with pure-js, and the production speed of the native module. Also there is the ability to run client side (mesh networks with webRTC), and the ability to run this on architectures other than x86 where the native version won't compile.