[biot]

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.

[huxley]

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.

[biot]

The Envato post says the passwords will be individually hashed and salted. The aMember forum has a few more details:

4.1.3 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Removed user.pass variable from email templates. Plain text password in not available anymore."

4.1.6 release: http://www.amember.com/forum/threads/amember-pro-version-4-1... states "Closes #448 - and do not save md5 passwords at all".

User issue: http://www.amember.com/forum/threads/urgent-amember-v4-1-12-... "Unfortunately, in the email received by customers, the password comes out encrypted like $P$BkTNDykCkTfsOqHwsV4TT2/"

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.

[tptacek]

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.