4 ms·
Note that bcrypt.hash just calls bcrypt.hashSync anyways[0]. So there it's still going to stall exactly the same amount. edit: Looks like it depends on which
by dsp1234 11y ago
Note that bcrypt.hash just calls bcrypt.hashSync anyways[0]. So there it's still going to stall exactly the same amount.
edit: Looks like it depends on which version you use.
'npm install bcrypt'[1] gives a version which supports true async usage (via V8 async callbacks in native code)
'npm install bcrypt-nodejs'[2] gives a pure JS version which I linked to. Which is the top search result for 'nodejs bcrypt'
[0] - https://github.com/shaneGirish/bcrypt-nodejs/blob/master/bCrypt.js#L630 https://github.com/shaneGirish/bcrypt-nodejs/blob/master/bCr...
[1] - https://www.npmjs.com/package/bcrypt https://www.npmjs.com/package/bcrypt
[2] - https://www.npmjs.com/package/bcrypt-node https://www.npmjs.com/package/bcrypt-node
[3] - https://www.google.com/search?q=nodejs+bcrypt https://www.google.com/search?q=nodejs+bcrypt
- __abc 11y agoBUT NODE.JS IS NON BLOCKING?!?@?!?!?! Kidding.
- EGreg 11y agoIt's IO-bound. I guess they could make a version that yields and resumes several times though!
- novaleaf 11y agolol at pure js KDF's
- novaleaf 11y agowow that's some serious downvotes. Why? a 1 second KDF function on a GPU will take upwards of a minute in javascript ... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.
- Klathmon 11y agowhere are you getting those numbers from?
- novaleaf 11y agomy own testing. maybe not a 1 sec to 1 minute factor though. see my other reply in this thread a few seconds ago.
- minitech 11y agoI 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 agowhen 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 agobut 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.
- 11y ago
- warfangle 11y agoAnd 'npm install bcrypt' is the package linked to from the article.
- mbell 11y agoThe project from the article is https://github.com/ncb000gt/node.bcrypt.js https://github.com/ncb000gt/node.bcrypt.js There, the encryption is handled asynchronously, the event loop is yielded while the calculations take place in a C extension.