In of itself, the statement isn't incorrect though is it? Are you sighing because you believe the statement implies a poor hash function will be chosen?
It's not incorrect, but it's somewhat telling that such a massive vulnerability that they were fully aware of "has been running for a long time" and rather than fork over $179.95 for the new version of aMember which would have completely fixed the vulnerability, they chose instead to let the vulnerability remain while they embarked on a greenfield project to rewrite their membership system from scratch. This rewrite would take an indeterminate amount of time whereas they could have paid a paltry sum for the upgrade and implemented it in less than 48 hours... as they just did.
I get that it's a prioritization issue. I've worked at places where legacy software had poor security practices and it's often a judgment call as to the risk of just letting it be vs. taking the time to rewrite whatever insecure portion remained. Often the decision is to leave it when it's a one-off project that will be shut down within a month, there is a limited attack surface involved, and the data being stored insecurely is very low value. On the other hand, security issues affecting the very core of a website (the login system that 100% of a company's revenue depends on) should get addressed as soon as the vulnerability is discovered. Additionally, they state that a server was compromised... it's not clear whether this was a SQL injection exploit that happened to display the users table remotely with no privilege escalation, or whether the server was compromised via a poorly chosen SSH password or similar and they may be dealing with a situation where rogue code is still living on one or more servers.
Do you happen to know what the new version of aMember uses for password hashing?
I saw some mentions of MD5 in forums and some handwaving about how other scripts use custom password security, but nothing definitive.
We looked at aMember for a project several years ago, before we switched to Django for all our development so I haven't kept up on what is available security-wise on PHP.
The hash format indicates it's using PHPass: http://cvsweb.openwall.com/cgi/cvsweb.cgi/projects/phpass/Pa... which is based on MD5, but with the log of the number of rounds indicated by the first character after the $P$ prefix. In the forum example, it's "B" which is 11 making it 2^11 rounds. The remainder is an 8 character salt plus checksum. PHPass is authored by "Solar Designer" or Alexander Peslyak, also the author of John the Ripper and respected in the security community: http://en.wikipedia.org/wiki/Alexander_Peslyak so is likely pretty solid.
Solar Designer is great. Here's what his PHPass page says:
The preferred (most secure) hashing method supported by phpass is the OpenBSD-style Blowfish-based bcrypt, also supported with our public domain crypt_blowfish package (for C applications), and known in PHP as CRYPT_BLOWFISH, with a fallback to BSDI-style extended DES-based hashes, known in PHP as CRYPT_EXT_DES, and a last resort fallback to MD5-based salted and variable iteration count password hashes implemented in phpass itself (also referred to as portable hashes).
To ensure that the fallbacks will never occur, PHP 5.3.0+ or the Suhosin patch may be used. PHP 5.3.0+ and Suhosin integrate crypt_blowfish into the PHP interpreter such that bcrypt is available for use by PHP scripts even if the host system lacks support for it.
Individually salted passwords will store the salt right next to the password and hash in the database. Then, when the database gets downloaded (which is presumably what happened), then the attacker can buy one of those new fangled Radeon cards and unsalt the stored hash and try passwords at the rate of hundreds of millions per second. Salting will not measurably slow this process down.
Salting prevents effective use of rainbow tables. It does not protect against brute force attacks, which are now incredibly cheap.
Individually salting passwords was best practice internet eons ago, not now.
Best practice is to use a work-adjustable scheme such as provided by bcrypt.
But salting is also fundamental in bcrypt. Using an function with adjustable work factor doesn't mean salting is not a good idea. Any cryptologic hash people will mention as a best practice will generally have the notion of salting built-in.
Virtually no-one implements bcrypt themselves. If you use a bcrypt library, you don't need to think about salting. Therefore, when someone says "they're using individually salted passwords", you can usually count on the fact that they're using a crappy password hash, but that they think they're doing something cryptographically sophisticated.
Not really related, but the popular python library for bcrypt kind of does make you have to think about salting. (And it has some other, er, 'curious' design decisions as well)
Well, the point of an adaptable work factor is that you can keep increasing the cost to generate the hash. The aim is for bcrypt is to be able beat Moore's law, not just be a short-term stop gap.