[pjscott]

That's part of bcrypt's reason for existing. In order to protect against brute-forcing stolen hashes, bcrypt has to be slow enough to make brute force impractical. This isn't a bug; it's a necessary feature. If the server they're running npm on is so old or so overloaded that the slowdown from using bcrypt would even be particularly noticeable, then they have other problems.

[tomjen3]

Oh it can surely run bcrypt for a few users. The question is if it can run it for a couple thousands a minute.

I am not so sure of that.

[tptacek]

The sites that have easily scaled bcrypt include many so large that this argument has basically been mooted, but if you want to nerd around with it: you would hypothetically just turn the cost factor down to accommodate load.

[grandpoobah]

It doesn't need to run it for a couple thousand a minute, there aren't that many people registering with NPM at any given time.

[tomjen3]

Sure, but how many people are using it? You would need to verify the password on each request (since you can't use browser cookies).

[pjscott]

The operations npm needs to log in for are a fairly small percentage of the total. If you need to upload a new version of a package, then that takes a password. If you just need to search for a package, or download its latest version, those don't need authentication. The overhead from using proper slow password hashing would be minimal.

And evidently the CouchDB guys agree with me, because they switched to using PBKDF2 for password storage -- essentially, iterate SHA several thousand times to make it slower.

[grandpoobah]

Wouldn't npm client be sending the hashed version of the password rather than the password itself? then the server only has to compare the two hashes.