The detailed story of our new security system

Hi this is Jason, founder of WP Engine.

1. The password is question is stored by WordPress in plaintext on disk.

2. It was transmitted to you inside our SSL-secured support system, because you requested it.

3. We maintain Pingdom reports on all our competitors, so I know for a fact that our uptime and speed is superior, in general.

HOWEVER -- I do NOT DISAGREE with your characterization that you might have seen slowdowns, poor support, etc.. With 1000s of customers, one thing we see all the time is a handful who, for whatever reason, really do have a terrible experience with us at every turn -- technical and human -- and it's just bad.

Of course there's the opposite end of that range of luck, and the huge majority who are happy and don't experience those things in those doses.

It's always frustrating to hear that you've had that experience -- all the more because I'm sure you're not exaggerating.

It's some consolation that we get praised daily on Twitter for just the opposite -- that shows we're not, in fact, just completely awful as you're implying.

But not much, because it always sucks to see even one customer have a series of bad experiences as you have.

Who else do you use, then?

I actively avoid using wordpress, and even more actively avoid hosting it, because it is such a security mess. But I doubt you've moved away from wordpress itself. It would be nice to have a "good" wp hosting option. Wordpress.com seems to be the best choice at the low end, and I guess WP VIP if you are very high volume, but I haven't really made a comprehensive study.

> The went ahead and sent us our password in plaintext. (actually a screenshot of the password in plaintext).

Sounds more than reasonable to me. After you get it, then you can use it to log in, and change it.

I came away with the same impression--they have no idea how it happened.

In their defense though, Wordpress by default lets site administrators directly edit PHP template files through a browser textarea. That means a lot of security is riding on user-set passwords.

Normally I'd say that could be mitigated by denying apache write access on the core files. But doing so would break the ability for users to initiate core updates via the web browser.

So if you can break/guess an admin password, you can upload arbitrary PHP code which has full write access to the appplication files. There's not really any way to secure that. I'm sure that's why Wordpress.com does not run individual full instances of Wordpress--it's the world's largest multisite installation of Wordpress and site owners can't touch the core files.

Wow, I missed that when I read it. Jason is an excellent writer/marketer.

But some plans can have an unlimited number of sites, I think.

Would it be so hard to use a journalling filesystem, snapshot backups, or even throw the site folders into git (not the binary files, obviously!) - then you could view all changes made to the code recently, look for changes in common between the sites, and look for changes only within .php files, outside of times the site was being upgraded by the customer or host?

There's a good chance that if it's not a previously known vector, they've contact the author of the component with some opportunity to fix it before it's publicized and resulting in attacks from new parties.*

* I neither agree nor disagree with zero-day disclosure policies. I'm just noting the possibility that they could be aware of the vector and would rather not share that information yet, for various reasons.

How would Cloudflare help if the site is already compromised?