Hacker News Reader

Comment by lukev | Hacker News Reader

I think this says more about node.js than it does about the proper way to secure a password.

Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.

Everything is asynchronous but the linked article uses the synchronous versions of the functions for some reason... async versions exist and are recommended[1]

[1] https://github.com/ncb000gt/node.bcrypt.js#async-recommended

Do the async methods actually execute on a thread pool though? Or do they use enough async methods internally to periodically release the main thread enough to keep it responsive?

From a quick glance at the source, the answer to the first is no.

This one is truly async, it uses a libuv managed thread pool.

Yep you're right - disregard what I said above. :)

asynchronous doesn't magically make CPU-intensive tasks faster.

It does mean other tasks (e.g. serving pages to visitors) can still be run at the same time as the CPU-intensive task though, like most languages do when it comes to hashing passwords and logging people in

Correct, but it sure does stop your entire single-threaded process from blocking to the detriment of all other requests.

It says both. The hashing is computationally expensive and Node runs in a single process (if we ignore workers). They could have made an implementation that yields and resumes after several ms. or you can spawn a worker and send it jobs.

Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.

PHP is usually deployed in a FastCGI multiprocess setup, so the server will keep handling requests on the other processes while the hashing process is blocked.

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.

The blog post that HN is reading is served by PHP-FPM + nginx, without any extra special features to handle the load of an unexpected "oh hey we made it to the front page of HN".

It's also hosted on a relatively cheap VPS.

Considering the other article from HN today about Stack Overflow being able to handle their top-100 global Alexa rank traffic with one physical web front end, I'm impressed but not that impressed. PHP has been popular for a long time and lots of smart people have figured out how to make it pretty quick.

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 know thats what i ment with usually you give a fuck, i dont know any way you could run PHP single threaded on a server (i mean there sure is). But its something common you learn when you programm in the other languages i mentioned.

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.

> i dont know any way you could run PHP single threaded on a server

Using `php -S 0.0.0.0:80 index.php` would do it!

Even with mod_php you get 1 per fork with the prefork mpm, so this wouldn't even stop some Apache 2.2 box with php4 configured 10 years ago from accepting new connections.

Yes. That's why nearly every web framework is threaded by default. That includes everything you'll find in Ruby, Python, Go, or ASP.

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.

It's pretty new that Rails is arguably 'threaded by default', and many/most typical deploy setups for Rails still don't run with multi-threaded request dispatch.

But yes, I agree with you that that is why every web app _should_ be threaded.

That's why you spawn worker processes and servers. Evented IO is way faster than threads as NGinX and Node have shown.

It definitely does, and I think that's the GP's point.

Reply on news.ycombinator.com