You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it
[1] https://github.com/ncb000gt/node.bcrypt.js#async-recommended
From a quick glance at the source, the answer to the first is no.
I wonder whether threading really saves you, given that there are only so many cores in a system and password hashing is CPU heavy. Naively it seems a DoS would involve sending as many parallel requests as there are cores, which is not a lot and can easily be done from a single machine.
It's also hosted on a relatively cheap VPS.
For things like blog posts, I'm sad that Movable Type fell out of favor. The pattern of using dynamic server pages to edit blog posts and generate static files for your viewers just makes so much sense to me. Then again, these days we can host our single-page JS front-ends on S3 + CloudFront and hook them up to API gateway and Lambda / Beanstalk talking to RDS and "not have any servers" :)
I dont think it could get a real issue in a real environment, except someone really wants to fuck with you. But the some fail2ban on to fast requests should fix this easily as the hashes dont actually take that long.
Using `php -S 0.0.0.0:80 index.php` would do it!
Not serializing IO, but them stopping every worker just because one of them has some hard work to do is not a sane working model for web backends.
But yes, I agree with you that that is why every web app _should_ be threaded.
The one recommended in the article[0] actually includes a blowfish C++ binding, with both synchronous and asynchronous methods for comparing and hashing. That binding uses NAN[1] to queue AsyncWorkers. NAN uses libuv[2] behind the scenes to launch a thread[3].
0. https://www.npmjs.com/package/bcrypt
1. https://github.com/nodejs/nan
2. https://github.com/libuv/libuv
3. https://blog.scottfrees.com/building-an-asynchronous-c-addon...
Or you can do the bcrypt() inside your (PostgreSQL) database and add an extra layer of security by not directly exposing the hash (or even the whole password table) to the web server process (i.e. write a password check SQL function and allow only calling it, no direct table/column access).
I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved the hashing process into the web server.
The webserver framework I was using at the time logged all its queries to the database at the normal log level. It couldn't log an actual query string because we used prepared statements, but it reconstructed the query and substituted the parameters in.
Enormously helpful for debugging an issue, when you can just copy and paste a query out of the serverlogs. Although I would probably have preferred that it not do that at the normal log level.
Curiously, it never logged the http request string/parameters. When I wanted that I had to add my own code to the request handler.
Anybody here that knows if any of these is a valid replacement? https://nodejs.org/api/crypto.html
Unfortunately, the example used for the bcrypt node module is the async form of hashing. That library exports both sync and async forms of hash/compare.