3 ms·

I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well

I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well as far as password storage goes, so a pure JavaScript bcrypt is bad mostly because it’s blocking on Node and not because it’s too slow to be useful. Please don’t pull numbers out of nowhere.

novaleaf 11y ago
when I was figuring out password security I did some tests. on my phone (a galaxy s3) I got about a 40x slowdown of pbkdf2 versus an x86 server running a compiled version (C I assume). I suppose running the js version on a server might give a better runtime, but I'd think the point of a js KDF is to run on the client, not the server. edit: and I'd assume a GPU version would be faster.....
- 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 ago
    right, 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 ago
      In 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.
- minitech 11y ago
  The speeds you were seeing might have had less to do with the fact that it was JS and were more about the mobile device being much slower than the server, then. This isn’t really avoidable, but a 40x slowdown isn’t the end of the world for bcrypt. Important to note that the only advantage of hashing or prehashing passwords on the client is offloading work from the server. It doesn’t improve security (on a website). Re: GPUs: - One of bcrypt’s advantages is that its memory requirements make using a GPU provide much smaller returns compared to, say, iterated MD5: you can’t parallelize it as much. - The point of using GPUs to generate password hashes is generally only to break them, because GPUs can do lots of hashes in parallel. Your web service probably doesn’t need to generate that many hashes at the same time, and it probably isn’t otherwise running on a server with a computey GPU. Clients’ GPUs? Even less parallel, they’d generate on the order of one hash per year.

novaleaf 11y ago

when I was figuring out password security I did some tests. on my phone (a galaxy s3) I got about a 40x slowdown of pbkdf2 versus an x86 server running a compiled version (C I assume). I suppose running the js version on a server might give a better runtime, but I'd think the point of a js KDF is to run on the client, not the server. edit: and I'd assume a GPU version would be faster.....

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 ago
  right, 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 ago
    In 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.
minitech 11y ago
The speeds you were seeing might have had less to do with the fact that it was JS and were more about the mobile device being much slower than the server, then. This isn’t really avoidable, but a 40x slowdown isn’t the end of the world for bcrypt. Important to note that the only advantage of hashing or prehashing passwords on the client is offloading work from the server. It doesn’t improve security (on a website). Re: GPUs: - One of bcrypt’s advantages is that its memory requirements make using a GPU provide much smaller returns compared to, say, iterated MD5: you can’t parallelize it as much. - The point of using GPUs to generate password hashes is generally only to break them, because GPUs can do lots of hashes in parallel. Your web service probably doesn’t need to generate that many hashes at the same time, and it probably isn’t otherwise running on a server with a computey GPU. Clients’ GPUs? Even less parallel, they’d generate on the order of one hash per year.