Safely storing an application's API keys

Stephane MANKOWSKI stephane at mankowski.fr
Mon Jan 18 18:07:17 GMT 2021


Hi,

In Skrooge, we have a plugin to download prices from coinmarketcap. For
that, an API key is needed.
We decided that: If the end user wants to use this plugin, he will have
to request a personal API key and store it in Skrooge that will use it
to call the service.
By doing like that, we don't need to store the API key in a public area.
In fact, each user has its own key.

Regards.

Le 18/01/2021 à 17:28, Thomas Baumgart a écrit :
> On Montag, 18. Januar 2021 17:20:31 CET Volker Krause wrote:
>
>> On Montag, 18. Januar 2021 12:21:30 CET Jean-Baptiste Mardelle wrote:
>>> Hi all,
>>>
>>> For Kdenlive, we are planning to expand the use of online services to
>>> download ambiance music or videos for use in personal projects. To this
>>> purpose, most online services provide us an API key that is used to
>>> identify our app (Kdenlive) when querying their API.
>>>
>>> Does anyone have experience / advice on how to protect these API keys so
>>> that they are not publicly available ? Is there any KDE online service or
>>> framework helping to achieve that ?
>> We have a similar problem in KPublicTransport. As others said, I don't think 
>> keeping API keys secret is possible, they need to be handed out to the user 
>> eventually after all. This already doesn't really work for closed-source 
>> applications, and open source certainly doesn't make that any easier.
>>
>> Terms of services requiring protection of API keys are IMHO therefore mostly 
>> wishful thinking. I have talked to the providers of two of the backends we use 
>> in KPublicTransport about this, they understand the problem and are ok with 
>> having the API keys in public source code. That might be the more realistic 
>> approach.
> It's what I did in the context of KMyMoney and HBCI online access. It's not
> strictly an API key but only used as identifier for the application, but
> nevertheless that number is in the KDE repos after I have confirmed that it is OK.
>




More information about the kde-devel mailing list