[pwny]

False. Getting broken through will happen because there are so many holes to plug, while strong and slow hashing + salting (while being extremely easy to set up) will make it so it's not even worth it for the attacker to crack passwords when he/she inevitably gets in.

Of course we need to plug holes in security and prevent people from getting in (SQL injection vulnerabilities are just as important an offence) but might as well protect the user's information when a breach happens. Especially since it's so much easier than the other way around.

[UnoriginalGuy]

What is "false?"

You deeply over-estimate how much effort it takes someone to break even correctly protected hashes. Most passwords are extremely poor and can be broken even without a rainbow table in less than a couple of hours.

Hell I can spin up an EC2 instance right now for free (AWS Free) running Linux and then just leave it there for 12 months at zero cost; giving me a nice formatted list of e-mail addresses and passwords to be used on third party sites.

At the end of the day most of these break-ins are news because the "hacker" got into a position to crack the user's passwords at all. What they do once they're in is not nearly as interesting from a learning perspective as how they got in originally.

Why, for example, are user's passwords on web-facing servers at all? Why not use several commonly available login API infrastructures to off-load that task to a firewall-ed box that can only be managed via VPN?

It isn't that crazy. It isn't that expensive either. A lot of software suites at minimum support a Kerberos protocol.

[pwny]

While I completely agree with you that the attacker getting into the database is an issue in the first place, "what is false" is that this is an excuse to divert the problem from blatant lack of understanding of basic principles in security.

My way of seeing this (and you might have a different opinion, which I respect as well. I want it to be clear my comment wasn't a personal attack) is that I use a strong password that would not be easily crackable by dumb bruteforce or rainbow tables. Therefore even if an attacker breaks in to a service that I use, steals database tables containing hashed and salted passwords and gets cracking, the likelihood that he/she breaks MY password is relatively low. Now the minimal effort from the company providing the service went to great length to complement MY effort of choosing a strong password.

There are a lot of problems in security. Weak passwords and password reuse are the burden of the user. Correct storing of passwords and preventing intrusions are the burden of the developer. Neither of those are an excuse for skipping hashing and salting because "it can be broken easily". You mention 12 months yourself, I'm sure my bcrypt'd/salted 16 character non-dictionary word unique password would discourage any cracker (and take more than 12 months to crack) and all of that was a lot easier to set up than a dedicated password storage solution.

Point is, do whatever you can to protect data. Better safe than sorry.