Is it recommended to use bcryptjs instead of bcrypt?

core
1

bcryptjs
optimized bcrypt in plain JavaScript with zero dependencies

"dependencies": {},

bcrypt references the following packages

"dependencies": {
    "@mapbox/node-pre-gyp": "^1.0.0",
    "node-addon-api": "^3.1.0"
  },

These packages are referenced again by @mapbox/node-pre-gyp

"dependencies": {
    "detect-libc": "^1.0.3",
    "http-proxy-agent": "^4.0.1",
    "make-dir": "^3.1.0",
    "node-fetch": "^2.6.1",
    "nopt": "^5.0.0",
    "npmlog": "^4.1.2",
    "rimraf": "^3.0.2",
    "semver": "^7.3.4",
    "tar": "^6.1.0"
  },

Then, a series of problems arise, including these errors

#16 2.367 npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
#16 2.664 npm WARN deprecated har-validator@5.1.5: this library is no longer supported

#16 2.425 npm WARN deprecated node-pre-gyp@0.14.0: Please upgrade to @mapbox/node-pre-gyp: the non-scoped node-pre-gyp package is deprecated and only the @mapbox scoped package will recieve updates in the future
#16 2.711 npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
#16 3.081 npm WARN deprecated har-validator@5.1.5: this library is no longer supported

All in all, bcrypt can cause problems and is often not installed when deployed

Why refer to a package that raises all sorts of questions, instead of choosing a better package?

Anybody agree with that?

For those of you who have been tortured by bcrypt, give it a like

2 Likes
2

I think the rationale of native bcrypt is the performance gain, though I will admit that usually password hashing I’d a tiny portion of the workload.

How have you been tortured by bcrypt? Mostly I just install it and it works

1 Like
3

From the npm page of bcryptjs:

While bcrypt.js is compatible to the C++ bcrypt binding, it is written in pure JavaScript and thus slower (about 30%), effectively reducing the number of iterations that can be processed in an equal time span.

This is the main reason.

4 Likes
4

I don’t know the number of rounds being used for Meteor, but the default bcrypt salt rounds is 12. According to the package owner, that is 2-3 hashes per second on their test machine. 30% slower can result to around a second per hash. Given the diminishing attention span of users especially in mobile, every second counts

3 Likes
5

Let’s please clarify the current title of this thread:

It is recommended to deprecate bcrypt and replace it with bcryptjs

The title sounds as if there was a wide consensus in the community about this, but I fail to see that. While it may seem to you as though it was better to replace bcrypt and use bcryptjs, there are good arguments against it.

Accordingly, I’m now changing the title of this post to a question, in order not to suggest a consensus which is simply not there, as follows:

Is it recommended to use bcryptjs instead of bcrypt?

4 Likes
6

My understanding is that bcrypt is designed to be slow; it’s actually a feature of it and what helps make it secure. The longer a crypto algorithm takes, the less prone it is to brute force attacks. Increasing the number of rounds is intended to lengthen the amount of time it takes to hash - we don’t want to allow more hashes per second as processors get faster.

You actually don’t want to be able to do more hashes per second, as that allows computers to more easily brute force passwords, which is compounded as processor speed increases.

Now, keep in mind that it is “slow” for computers; it will be nearly imperceptible to humans. Considering that the only time encryption would be done is during things like login, register, or changing your password, the slowness doesn’t affect humans much.

1 Like
7

The actual design of bcrypt intends the hash duration to be this long:

normal users: 250ms
superusers: 1000ms

The number of rounds must be tested against the server that you are using to achieve this minimum processing time (which changes as cpus become faster)

But nothing is stopping you to set the hash duration to 10s if you don’t believe that they have an effect to your users and server resources

2 Likes
8

Oh cool, I didn’t know those specific numbers.

When you said

I thought you were suggesting that faster encryption is better.

This is something that I’ve never been sure about myself; no idea what the best way to “fine tune” this is. Usually things like rate limits are what would prevent your application from being abused from a brute force attack (as in… something else would trip before the hash duration would protect you). I figure that if someone is trying to brute force your encryption, they likely have access to you data somehow… and the attacker could just run the brute force on something more powerful than whatever server your application is running on. But I suppose if they have access to your data, you got bigger problems haha.

9

In a way, yes. But more about faster implementation of the same algorithm is better. With faster bcrypt, we get more rounds (more secured) at the same duration. We get the enhanced security without affecting our users or the server resources we need. And most of the time, what we are after is that middle ground between security and usability

1 Like
11

That makes perfect sense to me. Thank you.