If your development priorities are so unbelievably messed up they can't look into basic fundamentals like PBKDF2 or bcrypt, and you hoard large amounts of personal data, and you get compromised, and you think it's not your fault -- your company should not exist.

> Not that one either, we don’t recognize the author by name...and not the other one because we don’t like the owner of the company (who is not a developer).

This is quite obviously bad rhetoric (outright dumb, I'd say.) But let's say it's remotely true: you think "complete dysfunction, and inability to analyze root problems" -- that it's a reason why we shouldn't crack down these people?

Doctors make mistakes. Everyone knows that. Sometimes it's negligence, sometimes it's tragedy, sometimes it's just random happenstance or Friday the 13th or whatever. But for some reason, we don't interpret this as a blank cheque to let any jackass on the street legally operate on people, risking their lives, and then -- when they hurt someone -- we all throw up our hands, sigh, and say -- "well dang, at least Frito Pendejo, he tried really hard, tried his best and doctors, y'know, medicine is crazy and uncertain!!! there are no right answers!!!"

Yes, security is hard. If there were real consequences to data breaches, then maybe companies would think twice before collecting every scrap of personal information that they can get their hands on. Large databases of personal information need to be seen as liability, not as an asset.

The "how to hash passwords" discussion should be easy: use PBKDF2, which is an IETF standard specified in RFC 8018 (originally specified in 2898 from the year 2000).