[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Safely storing an application's API keys
From:       "Jacky Alcine" <yo () jacky ! wtf>
Date:       2021-01-18 18:15:07
Message-ID: 55a34279-4288-4811-a932-94c470967b4a () www ! fastmail ! com
[Download RAW message or body]

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. 
> 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]