Safely storing an application's API keys

[Jacky Alcine]

That just pushes the problem down to the user though, no? That's not necessarily user friendly (how many average people know what an API is or why they need keys). 

The mention of IndieAuth is notable since it removes this problem altogether but it's not widely adopted enough. I think that the mention of asking service providers for a "public" key might be optimal.

On Mon, Jan 18, 2021, at 10:07, Stephane MANKOWSKI wrote:
> 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.
> >
> 
> 
>