[CKAN-Security] Security Issue -- credential disclosure

Wed May 29 16:15:55 UTC 2019

Versions: Current master, 2.8.x and likely releases in at least the last 4 years.

https://github.com/ckan/ckan/blob/master/ckan/logic/action/get.py#L1434 <https://github.com/ckan/ckan/blob/master/ckan/logic/action/get.py#L1434>

API requests to /api/action/user_show?id=any_user from a sysadmin return the API key for the user. 
API requests to /api/action/user_list from a sysadmin return the api keys for _all_ users.

There are 2 problems here:
1) Any sysadmin can transparently impersonate any other user. 
2) These are the most dangerous credentials contained in the system, as they're unscoped plaintext username/password equivalents. While the password is protected with a reasonably state of the art key generation system, the api key is stored plaintext, so a database leak is instantly a full compromise. 

I'd recommend several independent courses of action here:

1) API keys should never be returned to other users.
2) API keys should be displayed once when generated, and from then on never revealed. If someone needs a new key, it should be regenerated. 
3) API keys should be stored in the database in a form similar to passwords, not in plaintext.

I'd recommend implementing something like AWS's id/secret key pair. In this case, for backward compatibility, it's going to be hard to keep the same format and have it not be a password equivalent, but something like: "key-id:uuid" as the api key could be split into id/hash portions, then the key-id matched in the database and run through the hash verification. 

Thanks,

Eric	

Eric Soroos, Senior Developer
Derilinx - Linked & Open Data Solutions

Web: www.derilinx.com
Email: eric at derilinx.com
Address: 11/12 Baggot Court, Dublin 2, D02 F891
Tel: +353 (0)1 254 4316
Mob: +353 (0)83 8730257
Twitter: @derilinx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20190529/f0a53aba/attachment.html>