It seem to me there is an issue with the way the API keys work in Campaign Monitor, that leaves the door open to security problems.
I need to put my manager API key into my clients software on their servers, in order for them to use the API to work on there accounts...
With that API key, a savy client could very easily take over my whole account, and gain access to all my other clients lists.
In order for my client to add a new subscriber to there list, they need MY API key, & List API key.
Should it not be CLIENT API key & List API key?
The only thing the master API key should be needed for is for calls that deal with managing clients.
I agree with this. Even though currently all my Clients that will be using CM are hosted on our servers, that might not always be the case.
Also, as a side note, flash should NEVER be used to access the API directly since it will make your API key publicly visible. You should instead hit a service on your webs server that then sends out the API request from the server itself, not the browser.
No comment at all from CM?? I think this is a serious issue, and would have expected some sort of comment..
You're right. Using the API methods that way is a security issue. Most people don't expose their API key to their clients, so it's never really come up before.
We've had a quick chat in the office, and an idea we've had is to provide and allow Client Authentication Keys, similar to what you've suggested. You would use them instead of the API Key, but you could provide them to your clients. How does that sound? Any extra feedback would be appreciated. We'll have a bigger discussion in the office about this topic in the future, and we'll let you know what we've come up with.
Sounds good to me- but I don't understand why you wouldn't just use the current Client API key? Is that being used for something else that would interfere with this?
Thanks for the response,
Ken, thanks for that. I agree with Jason though, and think it makes the most sense to use the client "ID".. In all honesty it already looks more like and API key now then a client ID being so long and all, but whatever solution you guys choose I appreciate it!
I assume that using a client API as well as client ID is for the sake of not having to rewrite a bunch of how the API currently operates..
Thanks for being so responsive! Its great to work with folks who listen.
I do find it odd that this has not come up before, as a simple thing such as a web form on the clients site that send the client info but also has an option of adding the visitor to the newsletter would seem the most common use of the API...
Regardless, this is great news and I hope it is something you can implement quite quickly...
Alex is partly right. There would be a client API authentication key so that we won't have to rewrite how the API works. Also, the client ID is just that, the client ID. We need a bit more data to do the authentication, data that I can't divulge to you (I would then have to kill you, otherwise ;) ).
We'll keep you up to date on how we go.
Rocking good news Ken, looking forward to seeing this in place!
Any news on this? I am very concerned about this. I found Kens comment "Most people don't expose their API key to their clients" very odd. The API has to be in the code on the server. Most clients have FTP access to there own server, so they would now have access to my "Master" API key and all my other clients data.
If any one could explain a way to include the API on a clients server in a "safe" way I would love to hear it.
I currently store the key in a MySQL database encrypted, but the code to "decrypt" it is in my software so any one with knowledge of PHP would be able to reverse engineer it to extract the API Key...
A client specific API is the only real solution. As it is now CM assumes every one using the API has a SaaS model, but that is not always the case.
I just found this topic looking for a solution to this very problem.
So let me just add my vote for client-based authorization - I agree that "not using the API from the client's server" is indeed an odd argument. In fact, I was pretty enthusiastic about CampaignMonitor as a new tool for me, until I stumbled upon this security hole.
Can you please keep us updated concerning if and when you intend to fix this?
Thank you very much. This is a great app otherwise, but this issue may be a dealbreaker for some people.
Just letting you know that we haven't forgotten about this issue and it's definitely still in our sights. It's just a question of prioritizing it with all the other tasks we have to do...
Just want to add my vote for a client level API key. This came to my realization when I installed the Expression Engine plug-in on a client's website and realized that they would be able to see a list of ALL of my CM clients and their lists by way of my API key.
Thanks for adding it to your priority list, Ken.
I'm also looking forward to use the client API keys! Any more new developments? :-)
I've added your vote for the feature request.
This topic is still being discussed around here. We do think the Client Authentication Key (CAK) idea is a good one. What we're trying to nut out now, is how to disseminate the CAK. We're afraid that listing the API Client Authentication Key underneath the API Client ID in Client Settings could cause confusion and more trouble than it solved ("What's the difference between the API Client Authentication Key and the API Client ID? Which one do I use in my API calls?")
If you have any ideas, we'd like to hear them!
How about a simple Explanation along with the keys.
API Client Authentication Key - Use this if your application only needs to access one clients data. If you application needs to access multiple clients data, than you should use your Account Master API key instead"
Or some such thing..
Does the fact that you are now trying to figure out how to display this data on the GUI mean that it is functional, even if not yet exposed to us??
Would be happy to do some Beta testing on this!!
We've actually changed tact, and we won't need the Explanation anymore. I won't spoil the surprise, you'll have to wait until we've deployed this feature.
The CAK has finished development and will need to go through Quality Assurance, along with the other features, bug fixes and improvements that are in the same release. So there is still some time off before it will be deployed... possibly one more month. We'll let you know here when it has been deployed.
I'm afraid you won't be able to do any Beta testing at the moment, as it will only be accessible to our internal environment. But thanks for the offer!
We can't wait! It will make Joomailer so much more awesome :)
Thanks Ken!! Glad to see you guys are so responsive to your users needs!!
Sorry Alex. Due to hacking attacks we've had to push back a lot of development as we've had to add a lot security features. We're only just getting back to our original timeline. I'm sorry for the continued delay.
Thanks Ken. Understandable and I am glad you are taking security seriously. Personaly I think this is also an important security issue as it is, as right now any of my clients could gain access to the rest of my clients accounts, as I have no choice but to post my "Master" API key on their servers...
I totally agree with you there Alex. We're moving as fast as we can on this. We'll keep you posted.
our vote on this issue!
@ken or anybody else:
is there a workaround until cm has solved this problem?
our clients want's to move on and send e-mails. so we have to bring a solution to keep our client on cm.
There's no need to add your vote anymore, since this feature is already complete in development! And now that we have finished and launched our latest milestone (A/B Testing), we can get onto QA'ing the next milestone, which includes this feature. So I estimate around 2-3 weeks before this is deployed.
I'm afraid there's no workaround it (that I can think of). I hope you can wait until we deploy the feature.