bcrypt.genSalt(10, function(err, salt) {
if (err) return; //handle error
bcrypt.hash(clearPassword, salt, function(err, hash) {
if (err) return; //handle error
// Store hash in your password DB.
});
});bcrypt.genSalt(10, function(err, salt) {
if (err) return; //handle error
bcrypt.hash(clearPassword, salt, function(err, hash) {
if (err) return; //handle error
// Store hash in your password DB.
});
});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/bCr...
[1] - https://www.npmjs.com/package/bcrypt
Kidding.
... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.
Please don’t pull numbers out of nowhere.
edit: and I'd assume a GPU version would be faster.....
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.
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.
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.
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.
There, the encryption is handled asynchronously, the event loop is yielded while the calculations take place in a C extension.
How does that look now?
Unfortunately a lot of people think that these functions are a simple way to "not have to deal with callbacks", which is not correct...
Is there any reason not to use the Sync functions if you're not writing a web server and don't particularly care for performance?
This may sound like "not a big deal", but even an operation that takes 1ms will cause noticeable lag at ~50 operations per second, and block everything approaching a thousand.
For emphasis: they block the entire event loop. Not a single request, not a single client, not a single operation or event. The entire application for every user everywhere.