The detailed story of our new security system(wpengine.com)
wpengine.com
The detailed story of our new security system
http://wpengine.com/2012/06/the-detailed-story-of-our-new-security-system/
6 comments
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.
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.
Doesn't WordPress support hashed passwords?
http://codex.wordpress.org/Function_Reference/wp_hash_passwo...
http://codex.wordpress.org/Function_Reference/wp_hash_passwo...
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?
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?
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.
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.
WordPress really isn't insecure if you use it and configure it correctly.
> 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.
Sounds more than reasonable to me. After you get it, then you can use it to log in, and change it.
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".
Did I miss it, or did none of the investigating and none of the hiring of 3rd party firms lead to tracking down the attack vector?
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.
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.
Possibly the most impressive thing is the disclosure they are hosting 30,000 sites.
At the lowest monthly plan cost of $29/mo/site thats a $10MM+ annual revenue business created in just 2 years.
Good job!
At the lowest monthly plan cost of $29/mo/site thats a $10MM+ annual revenue business created in just 2 years.
Good job!
But some plans can have an unlimited number of sites, I think.
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.
So the plan is leave this vector open (as it was never found) and just try to secure the file system a bit more...
Surly that could leave the same vector open to none file system attacks, ie MySQL?
Surly that could leave the same vector open to none file system attacks, ie MySQL?
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.
* 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.
I wonder if Cloudflare's free, 5 minute setup plan would have helped them?
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.