Hey services module users and developers,
I have a strong feeling the API key has an incorrect implementation in the services module.
Let me try to clarify and make a suggestion.
It's a good thing services can use API keys.
It's a good thing services then uses a hash to verify the origin of the request.
Therefore, the secret - used to generate the hash - has to be kept secret, of course.
Imagine this: someone succeeds in stealing an API key - secret combination (by hacking the client's server or by reverse engineering intercepted webservice requests or...).
You - as the webservice administrators - notice that some API key gets abused (by keeping an eye on your webservice log files or by means of someone reporting the abuse to you or...).
You'll want to give a new secret to the person related to the API key (and advise him/her on security best practices) so the hacker can't use the stolen secret any more and your client's application can continue to function as intented.
The problem is: services module uses the 'API key' as secret.
Whereas "normally" (cfr. Facebook, Flickr, ... API docs) an API key is a public key and the secret (a seperate key) is the private key.
At the same time: services module uses 'domain name' as public key.
If you try to edit the details of an API key (using the services admin interface) you'll notice that:
- API key: not editable
- 'title of the service key' and 'domain name': editable
Whereas, if you ask me - and here comes my proposition -:
- 'API key' stays unique and remains non-editable, but gets used as a public key.
- we add 'secret', which is editable or can be reset/regenerated, and gets used as a private key.
- we remove 'domain name' from hash calculation as it belongs to the API key's extra/account information, such as 'title of the service key' (and maybe - in the future - 'contact name', 'contact email address', ...)
Can anyone agree or disagree on this?
Greetings,
Pieter
Jeugdwerknet.be employee
Comments
This sounds pretty
This sounds pretty reasonable to me.
Just gotta implement it! :-)
Screenshot
I got pretty far on implementing this, as you can see on the little screenshot.
I might want to link it to a user (id) and create an end-user interface, so he/she can login on my site and view or regenerate his/her secret key. Which makes it more secure compared to me - as an administrator - having to email the key and secret to the end-user (as mails also can get in wrong hands...)
Anyway chrism2671, I'm glad you took a moment to read my proposition and posted your opinion.
Greetings,
Pieter
Can you put this as a patch
Can you put this as a patch so others can test?
Created a patch
Issue created and patch attached, see: Wrong usage of API key as secret key
PieterDC, I like this idea,
PieterDC, I like this idea, but it also has flaws. Think in terms of clients that can be decompiled/sniffed (e.g., Flash). Your secret is not so secret, then.
I honestly don't have any silver bullet either, but I think a better solution is to make the key on the fly. So the server knows how to create the key (based off time and some other random vars), then md5. However, even this can be hacked in the same way yours can. This situation is just a bit more frustrating and a lazy hacker might give up faster :)
The bottom line is that we can never trust the client, but we have to. The best thing you can do is 1) don't expose API that can has injection issues, etc (obviously) 2) verify calls on the server (i.e., if the same service call was made 5 times within a couple of seconds, it's like some is using a proxy and a call repeater) 3) don't expose API that can modify chunks of your site that are hard to revert or can hinder it. 4) keep a log of every call in case you get hacked.
The reason FB's "secret" works is because it's server to server. There's no way a hacker can see the source. That may be the case with Services in certain circumstances, but more often than not you're going to be dealing with Flash or some other client that can be decompiled.
Btw, I would LOVE to hear other ideas on this because it's a huge issue that needs to be tackled asap
Matt
Large Animal Games | www.mattwkelly.com
Matt
Facebook | www.mattwkelly.com
Given that this is exactly
Given that this is exactly the way all big players are doing webservices,including Amazon with its super critical S3 service, I doubt that your fears are founded. Can you explain how decompiling the client could matter ? The point is to give each user using the clients a pair of secret/public keys, just like facebok does.
Also, I believe FB is doing client server, especially with facebookconnect.
My fears are founded because
My fears are founded because we've had people hack our apps and when we had the exact same solution implemented that you outline above.
Let me give you an example of why Facebook is different. In almost every case, the client is a server, right? I.e., a server running PHP that you can't decompile. So the secret will always be safe, unless of course someone hacks into the directory housing the secret and grabs it.
The issue with storing a secret is that the client has to know about it. In many cases, the client using Services is Flash. That means you have to compile the secret into the Flash build. That's not safe because it's cake to decompile a Flash app, sniff around a bit, and find the secret. Same thing applies for almost anything where the client isn't housed on our trusted server.
Does that make sense?
Matt
Large Animal Games | drupal.mattwkelly.com
Matt
Facebook | www.mattwkelly.com
I understand what you are
I understand what you are saying but it is different from the solution I am mentioning based on the proposition and which is implemented by big players. The important difference is that the secret is not compiled into the app. Rather, it is a runtime configuration parameter that each user must provide when running the app. And then, all you have to do is provide a different secret to each user. So even if they decompile, there's nothing there to get and it's safe. That's why this proposition works... if you use it correctly.
In your case there is absolutly no solution unless you also sign all messages coming from a device with a unique devide id of some sort that is associated with the user account... but that's really the same as having a secret given by the server to that specific user.
OAuth
Instead of guessing what's safe or not we should implement the standards that exist. I have a patch that adds pluggable authentication support to services that's currently being reviewed by marcingy. As soon as he thinks it's good enough I'll also publish the modules needed to implement OAuth as a authentication method for services.
This way people can use standard libraries and workflows for handling authentication when communicating with services.
Re: OAuth
"OAuth enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers."
This isn't always the purpose when using Services module with Drupal.
That said, my proposal above is inspired on/ was written after reading the oauth tech specs.
I'd love pluggable authentication methods for Services, but not without a decent default one for Services itself.
subscribe
subscribe
OAuth
OAuth will become the new default authentication implementation in services 3.x. And something thats worth to note is that OAuth can be used without a authorization workflow. Either through pre-distributed tokens and secrets, or by using OAuth as two-legged.
Cool
Ah, cool. Didn't know about that.