[UnoriginalGuy]

In principle I agree: it is bad practice.

But let's remember that either plain text or one-way hashed they will be broken eventually. The only thing hashing passwords buys you is a little bit of time before the "hacker" can use those passwords to access the compromised system.

It doesn't, for example, protect you from password re-usage issues. You also have to reset the passwords either way.

I think getting broken into is the biggest problem here; everyone has recently spent far too much time talking about hashes instead of asking questions about how the real break-in occurred at these businesses.

[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.

[Smerity]

The issue is that if I were a hacker I'd have a program that: a) takes an email and password, b) checks if email is in ["gmail", "yahoo", "msn", "facebook", ...], c) attempts to access account using given password and then d) if successful, changes password / mines data.

This is not difficult. There may even be programs that already exist for this. The only difficulty would be not getting blocked by those services after a large number of incorrect attempts, but leverage services like Tor/EC2/botnets and that becomes a null issue.

With password hashing it would at least be _some_ amount of time between accessing the leaked data and havoc. Cleartext means disaster is instantaneous.

[yashchandra]

"I think getting broken into is the biggest problem here"

Perhaps. But that still does not undermine the importance of storing passwords securely with encryption. The idea is not to completely avoid an attack (crackers are pretty determined ), the idea is to delay or make it harder for the bad guys. so yes, encryption matters a lot.