Re:How to Safely Store Your Users' Passwords in 2016
by sarciszewski on Wednesday February 17, 2016 @02:32PM
(#11120537)
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.
Re:How to Safely Store Your Users' Passwords in 2016
by seanp2k2 on Thursday February 18, 2016 @02:26AM
(#11124241)
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" :)
Re:How to Safely Store Your Users' Passwords in 2016
by herbst on Wednesday February 17, 2016 @05:16PM
(#11121918)
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.
Re:How to Safely Store Your Users' Passwords in 2016
by girvo on Wednesday February 17, 2016 @07:31PM
(#11122760)
> 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!
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.