Is this true even when the attacker is specifically focusing on a single account, or is it only computationally infeasible to recover passwords for accounts in general?
"Since every user has their own unique random salt, two users who happen to have the same password get different salted hashes. [If] the dictionary attack is foiled, the attacker cannot compute the hashes of every word in a dictionary once and then check every hash in the table for matches anymore. Rather, the attacker is going to have to re-hash the entire dictionary anew for every salt. A determined attacker who has compromised the server will have to mount an entire new dictionary attack against every user's salted hash, rather than being able to quickly scan the list for known hashes." [0]
[0]: http://www.developerfusion.com/article/4679/you-want-salt-wi...
If the answer is "it would take $1000 worth of Amazon EC2 computing to crack a single weak password", well, that's certainly feasible to do if you have a specific target in mind.
I'm assuming that your "8 character password" is assuming a randomly-generated password. I'm curious what the expected cost would be of breaking a particularly weak one (e.g. a human-generated password, based on dictionary words although perhaps with mnemonic devices or letter/number substitutions). The paper you linked says their hardware computed 6511 passwords per second at a cost factor of 5, and based on the cycle costs listed, I'm thinking it does 52 passwords per second at a cost factor of 12. Assuming a particularly weak password, I don't know how many passwords a brute-forcer would expect to have to try before hitting the correct one.
The paper goes into estimated costs as well, but I'm not going to dig through it to figure out how much it would actually cost to run that hardware for a month straight. And of course it's talking about dedicated hardware, which Slack's hacker almost certainly doesn't have.
Someone could go through the list of the top million passwords in a week of CPU time and, because each hash has its own randomly generated salt, the effort spent cracking one user's password yields no insight into anyone else's password; the entire effort needs to be repeated per user. If your password has sufficient entropy (eg: long and randomly generated, not appearing in any password lists) then -- barring some revolutionary mathematical breakthrough -- you don't need to worry about someone discovering your password before the heat death of the universe.
Hashing functions like bcrypt are intentionally set up to be computationally expensive, so that when brute-forcing a password, attackers can only try, say, 1 thousand passwords per second, not 10 million, on any given computational unit. The exact numbers of attempts-per-second depends on the attacker's computer, and the exact setup of their password hashing.
When trying to find the password for a particular hash, which is a hash of a strong password, there's really no better way than trying all possible passwords, hashing them, and seeing if they match.
When attacking a whole database at once, sometimes you get lucky and some accounts have weak passwords, and those you crack quickly.
// this is about focusing on a single account. Nobody would ever bother with trying to crack the whole DB.
Even if it's a gmail user, if you get them, and they use the same password on their mail, poof, you're in.
What gets me is that banks of all places have the worst password abilities (for their web logins)... case insensitive, only letters and numbers.