We recently had to switch off WP-Engine. We were on for ~9 months and it was frustrating because there were be regular slowdowns. The responses that came back were things like "someone else on your server had a runaway script that was eating all the CPU" and other things that made us feel pretty vulnerable.
Eventually the site became so slow so regularly that we were pretty sure we were going to switch to another host.
The final straw for us though was that we had an interaction with tech support and we needed to retrieve our password.
The went ahead and sent us our password in plaintext. (actually a screenshot of the password in plaintext).
So, to put it mildly, blog posts like this feel like a veneer to us. Slow, vulnerable and poorly secured.
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.
I would really like you to elaborate on how "The password is question is stored by WordPress in plaintext on disk"?
If you're referring to the database password that is stored within wp-config.pnp, why is it even the same as the account password? Does the customer even have direct database access? If not, can you explain why the db password is the same and why it isn't a randomly generated pass?
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.
Nope. Your password shouldn't be stored in plaintext in the first place. It should be properly salted and hashed with a modern hashing function like bcrypt. Storing passwords in plaintext turns security breaches from "that's annoying" to "oops we just exposed 12 million passwords".
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.
Ironically the security of Wordpress being so bad is why I'd use an outsourced host in the first place. It is one of the pieces of software I hate to run, and if I do, it goes on a dedicated vm.
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.
If they knew the source of the attack and closed the hole, they'd want to have said so. They don't need to say what the hole is or how they closed it to do that much.
Eventually the site became so slow so regularly that we were pretty sure we were going to switch to another host.
The final straw for us though was that we had an interaction with tech support and we needed to retrieve our password.
The went ahead and sent us our password in plaintext. (actually a screenshot of the password in plaintext).
So, to put it mildly, blog posts like this feel like a veneer to us. Slow, vulnerable and poorly secured.