v3 is inherently insecure

Just curious — do you think the same security concern applies to the v.1.3.x plugin?

It does although previously the plugin allowed configuration of settings without utilising an API key (on v3 the first screen presented forces the user to)

Hi @turn-on-social,

While I agree that OAuth 2.0 would be more secure than our current approach I disagree that the plugin is vulnerable. The threat scenario you describe depends on the blog itself being compromised, the security of which is completely separate from that of our plugin.

If you have a proof of concept for vulnerability in our WordPress plugin we would love if you reported it here:
https://hackerone.com/cloudflare

Thanks,
John

Fair enough.

Asking customers to put their global API key in plain text on multiple WP sites seems like a substantial security risk. Much better to isolate it in some way with domain specific API keys for example.

Just following good security principles.

HI @jwineman

Isn’t that a bit like saying if you leave your debit card pin number written on a piece of paper in your wallet locked in a car, then the security of the car is the only issue?

I would argue that in the instance that the car was broken into it would definitely be your own fault if you left your pin number written down with your bank card.

Good analogy @zandercent!

In that case, a copy of that pin would be locked in your car, your house, your office and your briefcase. If any one of them were ever opened, this would reveal the pin providing access your bank.

Not only that, the person who finds the pin would also get access to all the other bank accounts you own – since a master key opens access to all your CloudFlare domains without exception.

• This reply was modified 8 years, 2 months ago by Turn On Social.

My point is this – if someone hacks your blog then they don’t need your CloudFlare API key, they already have access to your entire site and can do whatever they want.

No matter what authentication scheme you use you still have to store a secret (API Key, Oauth Token) some where. There is no way to store that secret in a way that isn’t accessible to an attacker who is able to gain root access to your blog.

Scoped keys don’t fix the vulnerability described above, they just limit the damage. In either case if an attacker hacks your blog they get access to a key that lets them manipulate your domain and in each case the solution is to revoke that key. I say this to point out that OAuth 2.0 is “vulnerable” to the scenario outlined above as well, just to a lesser degree.

Its important to distinguish between “insecure” (read: vulnerable) and security best practices. In this case the plugin is secure, but could be made more secure by using API keys with more specific scope.

Thanks,
John

Hey there,

I’m part of the security team at CloudFlare and have reviewed the WordPress plugin in the past.

I totally agree that being able to properly scope API keys to a limited set of functionalities and zones would be a huge improvement. In fact, it is something I have been actively working on for a while now (not just for our CMS integrations, but for the entire cloudflare platform).

Saying that the application is “inherently insecure” is just not accurate. John hit the nail on the head with a couple of his points. This is not a security vulnerability, but we all agree that it is not consistent with what best practices would dictate. We are always working to improve and provide mature security solutions and this is something we already started working to make better.

Evan

Yeah – just o be clear, I don’t really have much of an opinion on it either way, I just thought the reasoning was a bit off.

It is true though, one hacked site potentially exposes the key to all of them, no? I kind of consider Cloudflare to be a security company, so best practice not being adhered to is surprising… but I’m certainly not annoyed or anything, just getting involved!!