Comparing version 3.0.7 to 3.0.8
@@ -0,1 +1,6 @@ | ||
# 3.0.8 (2019-12-31) | ||
* Update `node-pre-gyp` to 0.14 | ||
* Pre-built binaries for NodeJS 13 | ||
# 3.0.7 (2019-10-18) | ||
@@ -2,0 +7,0 @@ |
@@ -14,3 +14,3 @@ { | ||
"main": "./bcrypt", | ||
"version": "3.0.7", | ||
"version": "3.0.8", | ||
"author": "Nick Campbell (https://github.com/ncb000gt)", | ||
@@ -34,3 +34,3 @@ "engines": { | ||
"nan": "2.14.0", | ||
"node-pre-gyp": "0.13.0" | ||
"node-pre-gyp": "0.14.0" | ||
}, | ||
@@ -37,0 +37,0 @@ "devDependencies": { |
@@ -37,3 +37,3 @@ # node.bcrypt.js | ||
> Per bcrypt implementation, only the first 72 characters of a string are used. Any extra characters are ignored when matching passwords. | ||
> Per bcrypt implementation, only the first 72 bytes of a string are used. Any extra bytes are ignored when matching passwords. Note that this is not the first 72 *characters*. It is possible for a string to contain less than 72 characters, while taking up more than 72 bytes (e.g. a UTF-8 encoded string containing emojis). | ||
@@ -129,13 +129,11 @@ As should be the case with any security tool, this library should be scrutinized by anyone using it. If you find or suspect an issue with the code, please bring it to my attention and I'll spend some time trying to make sure that this tool is as secure as possible. | ||
// Load hash from your password DB. | ||
bcrypt.compare(myPlaintextPassword, hash, function(err, res) { | ||
// res == true | ||
bcrypt.compare(myPlaintextPassword, hash, function(err, result) { | ||
// result == true | ||
}); | ||
bcrypt.compare(someOtherPlaintextPassword, hash, function(err, res) { | ||
// res == false | ||
bcrypt.compare(someOtherPlaintextPassword, hash, function(err, result) { | ||
// == false | ||
}); | ||
``` | ||
The "compare" function counters timing attacks (using a so-called 'constant-time' algorithm). | ||
In general, don't use the normal JavaScript string comparison functions to compare passwords, | ||
cryptographic keys, or cryptographic hashes if they are relevant to security. | ||
[A Note on Timing Attacks](#a-note-on-timing-attacks) | ||
@@ -155,7 +153,7 @@ ### with promises | ||
// Load hash from your password DB. | ||
bcrypt.compare(myPlaintextPassword, hash).then(function(res) { | ||
// res == true | ||
bcrypt.compare(myPlaintextPassword, hash).then(function(result) { | ||
// result == true | ||
}); | ||
bcrypt.compare(someOtherPlaintextPassword, hash).then(function(res) { | ||
// res == false | ||
bcrypt.compare(someOtherPlaintextPassword, hash).then(function(result) { | ||
// result == false | ||
}); | ||
@@ -215,6 +213,5 @@ ``` | ||
``` | ||
The "compareSync" function counters timing attacks (using a so-called 'constant-time' algorithm). | ||
In general, don't use the normal JavaScript string comparison functions to compare passwords, | ||
cryptographic keys, or cryptographic hashes if they are relevant to security. | ||
[A Note on Timing Attacks](#a-note-on-timing-attacks) | ||
### Why is async mode recommended over sync mode? | ||
@@ -275,2 +272,14 @@ If you are using bcrypt on a simple script, using the sync mode is perfectly fine. However, if you are using bcrypt on a server, the async mode is recommended. This is because the hashing done by bcrypt is CPU intensive, so the sync version will block the event loop and prevent your application from servicing any other inbound requests or events. The async version uses a thread pool which does not block the main event loop. | ||
## A Note on Timing Attacks | ||
Because it's come up multiple times in this project, and other bcrypt projects, it needs to be said. The bcrypt comparison function is not susceptible to timing attacks. From codahale/bcrypt-ruby#42: | ||
> One of the desired properties of a cryptographic hash function is preimage attack resistance, which means there is no shortcut for generating a message which, when hashed, produces a specific digest. | ||
A great thread on this, in much more detail can be found @ codahale/bcrypt-ruby#43 | ||
If you're unfamiliar with timing attacks and want to learn more you can find a great writeup @ [A Lesson In Timing Attacks][timingatk] | ||
However, timing attacks are real. And, the comparison function is _not_ time safe. What that means is that it may exit the function early in the comparison process. This happens because of the above. We don't need to be careful that an attacker is going to learn anything, and our comparison function serves to provide a comparison of hashes, it is a utility to the overall purpose of the library. If you end up using it for something else we cannot guarantee the security of the comparator. Keep that in mind as you use the library. | ||
## Hash Info | ||
@@ -327,2 +336,3 @@ | ||
[depsinstall]: https://github.com/kelektiv/node.bcrypt.js/wiki/Installation-Instructions | ||
[timingatk]: https://codahale.com/a-lesson-in-timing-attacks/ | ||
@@ -329,0 +339,0 @@ [shadowfiend]:https://github.com/Shadowfiend |
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
Sorry, the diff of this file is not supported yet
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
349
112018
23
+ Addednode-pre-gyp@0.14.0(transitive)
- Removednode-pre-gyp@0.13.0(transitive)
Updatednode-pre-gyp@0.14.0