<i>I anticipate the service will be coming back online in the next 24 hours, with all passwords reset, hashed and individually salted (a best practice)</i><p>Sigh.
NetTuts needs to mention which key derivation function they are using so the community can verify they didn't fuck up again.<p>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.<p>[1] <a href="http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/" rel="nofollow">http://net.tutsplus.com/tutorials/php/understanding-hash-fun...</a>
> I should also note that aMember had in the meantime released an upgrade to their service which deals with the issue, though an upgrade with our heavily modified system was a significant endeavour.<p>In the previous blog post:<p>> Our current Tuts+ Premium app makes use of a third party plugin that unfortunately stores passwords in cleartext (i.e. unencrypted).<p>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".<p>> 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.<p>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.
<i>this wasn’t a failure of, or a reflection of, the professionalism and integrity of our development or Tuts+ teams.</i><p>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.<p>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.<p>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?
i fail to understand how any decent web company does not at the very minimum hash passwords in this day and age. More importantly - a company who teaches people coding and often runs 'best practices for XXXX courses' each month.
At least give it to them for being straight forward and honest. Yes, they screwed up, but so have a lot of other companies that in my opinion hold much much more sensitive data about me.<p>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.<p>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.