Update on Tuts+ Premium Security Breach
notes.envato.com
notes.envato.com
Sigh.
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.
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.
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.
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.
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.
SHA1 and MD5 are trivial to crack as there are many OpenCL implementations made specifically to crack salted passwords.
I would also recommend that they use this opporunity to teach their web developing users about proper password storage, but after reading their php hashing tutorial[1], I think it's best if their users look elsewhere. The tutorial eventually recommends bcrypt after listing multiple unsafe solutions. I understand that the author is trying to build up to the solution, but the correct solution needs to be in the first paragraph. The incorrect solutions need to be clearly flagged so a beginner skimming through doesn't see "md5" and stop.
[1] http://net.tutsplus.com/tutorials/php/understanding-hash-fun...
Users have to have some level of trust. Like everything else in life.
There is no real disadvantage to saying which one and a lot of trust to regain.
In the previous blog post:
> Our current Tuts+ Premium app makes use of a third party plugin that unfortunately stores passwords in cleartext (i.e. unencrypted).
The previous post sounded like they were too lazy to change the authentication system to a more secure one. But they now said they had a "heavily modified system".
> I’d like to take a moment to be clear that this wasn’t a failure of, or a reflection of, the professionalism and integrity of our development or Tuts+ teams.
I think any capable developer should find it easier to add BCrypt into the password field than the heavy modifications. Once they are familiar enough with the plugin (for heavy modifications), it shouldn't take more than a day to make it secure.
How is it not? There is NO excuse for storing passwords in plaintext, on any production site. From what I've read, they had this system in place for a while, and planned "to get around to" switching to a more secure password storage method eventually.
Sadly, it looks like a massive security breach was the catalyst they needed to realize that you can't put issues like user password security on the backburner.
Now, we get the same reactive "we're sorry, we should have known better" from the tuts+ leadership, and a promise that things will be better in the future. Why does it always take a humiliating security breach for companies like this to realize just how important user security, and by extension, your users' trust, really is?
We already know they didn't write it, but we don't have enough other information to make any other judgements (and the blog post at least implies the above may have happened).
Not saying it's right for them to not take security as serious as they should have, but unlike a lot of other companies, they disclosed it immediately, came up with a game plan, apologized multiple times and are refunding users and offering others free stuff.
I've changed my password on the other envato services I use as a just in case and I still plan on using them in the future. They've always put together great and in-depth tutorials and are a great resource for beginners, hackers and experts.