There are 127 modules for bcrypt

[kevinburke]

I need to hash passwords in my application but I'm new to node.js development. Hashing passwords incorrectly can lead to an exposure of user data.

When I search npm for "bcrypt", a recommended way to hash passwords, I see there are 127 matching modules. It's not clear which of these are maintained, whether the algorithm in each is correct, which one has a default work factor that is too short, or which one I should be using in my application. The closest thing you can get to "proof" is a download count, but this is not necessarily the best indicator (nor is it clear that the package with the highest download counts is presented first).

It would be nice if npm provided more guidance here; maybe a butter bar that shows up on searches for "bcrypt", "md5", "sha256" with information on how to securely hash passwords in node.js would be helpful. "Are you trying to securely store passwords? Read our article about it" etc.

It would also be nice if node.js included a crypto module, as you can usually trust implementations in the standard library, though this may be too much to ask.

[aredridel]

Node's standard library tends to be small, so expect to use the registry more than in other languages -- and bcrypt isn't standardized through the same channels as most crypto is. Its history is from the BSD world instead. The equivalent in the crypto community is PBKDF2.

The module you probably want is bcrypt itself, and you likely want the package most-depended upon, especially most recently widely depended upon. Download count is a weak metric at best.

A "here's more background information" bar would be interesting, but that's a lot of work for a large registry to always keep up to date.

[rlidwka]

"Are you trying to securely store passwords? Read our article about it" etc.

I'm afraid it'll quickly be transformed into this:

---

Are you trying to securely store passwords? Read an advertisement submitted with keyword 'password'. You can also buy a PaaS which will store passwords for you. And here are a bunch of opinionated blog posts which won't help too.

---

Thanks, but no thanks. Registry is created to host packages, and that's exactly what it should do.

And bcrypt is... situational... pbkdf2 - doubly so. Learn what it is, think about why linux distros use sha512, think a little bit more about interoperability, maintainability, attack vectors... and then choose what hash function you should use. Those "Use bcrypt. Use bcrypt. Use bcrypt." articles are worthless.

[othiym23]

With all due deference, this isn't an issue that the npm CLI team can / will act on, so I'm closing it.

The npm web site is working on improved mechanisms for search and discovery that will start to come out over the next few months, and I agree with @aredridel that Node core is unlikely to expand its scope to include additional functionality, even when it's as useful as bcrypt (but why bcrypt and not pbkdf2? or scrypt?). It's a little arbitrary that Node includes whatever's bundled in OpenSSL and not other things when it comes to authentication, but that line was drawn years ago, and we've gotta live with it now.

[booch]

@rlidwka -- bcrypt, PBKDF2, and scrypt are pretty much the only algorithms that do consider attack vectors for password attacks. They use salting by default, whereas bare SHA512 does not. They employ key stretching, to slow down brute-force attacks significantly. SHA512 is optimized for speed -- which means attackers can try many more passwords in the same amount of time that they can test a single bcrypt or PBKDF2 password. In short, bcrypt, PBKDF2, and scrypt were designed for password encryption, while SHA512 is designed with other goals counter to the ones you'd want for the best password protection.

As for interoperability and maintainability, bcrypt and PDKDF2 are well-supported in many languages and have been stable for several years. If you need to interoperate with a less secure password-hashing algorithm, then you'll obviously have to follow their lead -- just like if you have to deal with another system that's storing passwords in plain text.

Please don't assume that people with Linux expertise have crypto expertise. And please listen to crypto experts when discussing crypto topics. (I don't pretend to be a crypto expert -- just enough to be beyond dangerous.) Crypto is very easy to get wrong, and the consequences of getting it wrong can be huge. And every crypto expert I've heard from says to use bcrypt, scrypt, or PDKDF2 for passwords.