Wrong usage of API key as secret key
PieterDC - January 11, 2009 - 14:27
| Project: | Services |
| Version: | 6.x-0.13 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | marcingy |
| Status: | postponed |
Jump to:
Description
See Proposition for a new services module's API key security model to read what's wrong with the current API key and domain name usage in generating the hash, etc.
If you apply the patch (and execute update.php):
* the domain name won't be used as hash parameter any more
* the API key will be used as public key
* a secret will be used as shared, private key
* you will be able to link a Drupal user to an API key. he/she will then be able to see (and regenerate) his/her secret.
* the service browser will continue to work as intended
| Attachment | Size |
|---|---|
| 20090111_services6.x-0.13_key_secret.patch | 14.55 KB |
| 20090111_services6.x-0.13_key_secret.png | 32.3 KB |
#1
#2
subscribe, looks good to me for smartphone apps where user accounts will require keys
#3
This is the right step, but not bullet proof. Clients that can be decompiled (the majority of the use, it seems--Flash) are still threats. See this for more info: http://groups.drupal.org/node/17578#comment-68329
#4
@MattKelly : see my reply, you need to assign a different key/secret to each user; not to assign a key/secret to your application !
#5
@MattKelly: nothing is bullet proof. The only thing we can aim for is to make things harder for abusers. If flash files contain passwords/keys, that's a problem for the flash architecture, not the services server. Maybe it's possible to store that sensitive data outside the flash file on a more secure place? But this question is a little off-topic here.
#6
This issue is very old obviously but it is worthy of consideration and I'm trying to clean out the queue before finally doing a stable release before year's end.
The problem with this patch it is going to break the vast majority of implementations out there since the vast majority of implementations use the current API key structure, and that's not really something I can do midstream. The current implementation has been vetted by the security team which is enough for me.
That said, I'd love a more robust key something and I think it's something we can tackle for D7 and possibly a 3.x branch of D6. So I'm marking this as postponed for future consideration. Thanks for the patch it is appreciated.