On Tuesday, iThemes posted an announcement that they had suffered from a security breach of their website and servers. The attackers had reached the servers which stored customer information, including email addresses, IP addresses, full names, and yes, passwords.

iThemes was quick to notify customers via their blog, social media, and their full customer email list about the breach. Approximately 60,000 users were affected. They warned that passwords were vulnerable. In the second update, posted today, they gave more information about passwords, in response to many questions from users.

It turns out that passwords were stored in plaintext on iThemes’ server. That is, obviously, very bad practice.

Why Would You Store Passwords in Plain Text?

This is how the membership software we started using in 2009 did it. There are a number of factors for this, none that will make much of a difference at this point or make anyone feel any better about it, myself included.

Know that it’s not because we did not value your data. As an organization, we have been working on a very large migration process that has required us to interlink legacy systems with the latest technologies. Anyone that has ever gone through that process understands the complexities and challenges.

Frankly put, it’s been something we identified as a potential risk and are working rapidly now to rectify this issue as fast as humanly possible.

It’s also worth noting that their customer database and iThemes.com users were affected, but customers that use their Sync product to manage their own websites were not. So if you use iThemes Sync, and utilized your site passwords to connect, those accounts and passwords were not part of this breach.

aMember and legacy membership platforms

The membership platform that Cory highlights in the update is aMember, a membership management system that’s been around for many years. aMember only introduced encrypted passwords in version 4, which was released in November of 2011.

I discussed aMember and plaintext passwords with some other folks that have a significant history with the membership platform, and there are some significant problems that anyone using aMember have experienced.

First, most folks heavily using aMember aren’t using it out of the box. At the time, most membership sites were doing significant customizations to aMember to achieve desired functionality. So when the v.4 update came out, it was a very difficult update procedure for people to take advantage of the features.

iThemes would even tell you that their current version of membership software doesn’t look much like aMember at all.

iThemes is also not the first to be hacked and their aMember passwords leaked. Tuts+ Premium had the same issue in 2012.

I discussed aMember at length with Pippin Williamson. He has done a lot of work on his brother’s membership site, CGCookie, which also used aMember until 2012, when he did a huge migration of tens of thousands of members to a new platform.

At the time, Pippin notes that aMember did not disclose passwords were stored in plaintext, so CGCookie had no idea that their users were vulnerable until they learned of the Tuts+ hack, wherein they put a planned migration “into hyperdrive.”

The problem with iThemes’ situation is that they knew of the plaintext passwords and didn’t address the obvious security vulnerability.

All in all, the migration for CGCookie took months to perfect and significant juggling of priorities by their team.

Ticking time bomb

Speaking with Pippin, migrating from aMember was not an easy task. Paypal’s IPN handlers (a payment notification system) were tightly linked to aMember and preventing customer accounts from being disconnected from the membership site took weeks of engineering. Additionally, simply upgrading to the newer versions was also terrible.

Many other WordPress companies have used aMember in the past as well, storing plaintext passwords just like iThemes today.

So, aMember has definitely been a problem before now, but iThemes has absolutely slacked in their prioritization of the issue. Simply put, it’s inexcusable to put users into long term risk if you know their passwords are stored in plaintext.

Read more