Posted by PieterDC on January 11, 2009 at 2:27pm
Jump to:
| Project: | Services |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
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 | Status | Test result | Operations |
|---|---|---|---|---|
| 20090111_services6.x-0.13_key_secret.patch | 14.55 KB | Ignored: Check issue status. | None | None |
| 20090111_services6.x-0.13_key_secret.png | 32.3 KB | Ignored: Check issue status. | None | None |
Comments
#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.
#7
sub
#8
Bumping version but to be honest I'm actually thinking it will be a case of won't fix.
#9
#10
Please do not post on threads issues that are not related to original issue.
#11
It is a case of wont fix since key_auth is going by by is 3.x and were no longer currentl working on 2.x