Re: On API keys...
Heather Laine wrote: > Tom Glod wrote: >> This is a great best-practice explanation. Perhaps someone can turn >> it into a blog post and put it on the site. > > Yes indeed. See Blog. https://livecode.com/best-practice-for-api-keys-and-security/ Tip: Dropping in-bound links to relevant content is a useful organization habit, making it easy for customers, prospects, and searchbots alike to discover the roads that lead to the site where the store lives. -- Richard Gaskin Fourth World Systems ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: On API keys...
Yes indeed. See Blog. Best Regards, Heather Heather Laine Customer Services Manager LiveCode Ltd www.livecode.com > On 25 Jun 2022, at 04:34, Tom Glod via use-livecode > wrote: > > This is a great best-practice explanation. Perhaps someone can turn it into > a blog post and put it on the site. > Thanks again > > > > On Fri, Jun 24, 2022 at 6:24 PM Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Mr. (Or should I say Doctor) Waddingham! This is a really brilliant essay >> on the risk, benefits and rewards in multiple scenarios concerning the >> storage of keys. I’ve mentioned before that I came up with the idea of >> “poisoning” the encrypted data before the data was transmitted. If >> intercepted in transit, the data itself could never be decrypted without >> knowing how it was poisoned and what was needed to “cleanse” it. And that >> would require access to either the API of the device doing the corruption >> or the cleansing, or else someone who knew the method. >> >> By using this method, all but physical and social vectors are nullified. >> And control of those vectors is an illusion. >> >> Bob S >> >> Sent from my iPhone >> >>> On Jun 24, 2022, at 13:22, Mark Wieder via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> On 6/24/22 10:04, Mark Waddingham via use-livecode wrote: >>> The only way to use these keys is from server scripts running on a >> server which you do your best to maintain the security of. Ideally these >> keys should be stored in files which are only readable by specific users - >> usually the web-server user which is running the backend scripts which >> needs to make the requests. >>> >>> Or as server environment variables retrieved only by server scripts >> which are not user-accessible. >>> >>> -- >>> Mark Wieder >>> ahsoftw...@gmail.com >>> >>> ___ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: On API keys...
This is a great best-practice explanation. Perhaps someone can turn it into a blog post and put it on the site. Thanks again On Fri, Jun 24, 2022 at 6:24 PM Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Mr. (Or should I say Doctor) Waddingham! This is a really brilliant essay > on the risk, benefits and rewards in multiple scenarios concerning the > storage of keys. I’ve mentioned before that I came up with the idea of > “poisoning” the encrypted data before the data was transmitted. If > intercepted in transit, the data itself could never be decrypted without > knowing how it was poisoned and what was needed to “cleanse” it. And that > would require access to either the API of the device doing the corruption > or the cleansing, or else someone who knew the method. > > By using this method, all but physical and social vectors are nullified. > And control of those vectors is an illusion. > > Bob S > > Sent from my iPhone > > > On Jun 24, 2022, at 13:22, Mark Wieder via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > On 6/24/22 10:04, Mark Waddingham via use-livecode wrote: > > > >> The only way to use these keys is from server scripts running on a > server which you do your best to maintain the security of. Ideally these > keys should be stored in files which are only readable by specific users - > usually the web-server user which is running the backend scripts which > needs to make the requests. > > > > Or as server environment variables retrieved only by server scripts > which are not user-accessible. > > > > -- > > Mark Wieder > > ahsoftw...@gmail.com > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: On API keys...
Mr. (Or should I say Doctor) Waddingham! This is a really brilliant essay on the risk, benefits and rewards in multiple scenarios concerning the storage of keys. I’ve mentioned before that I came up with the idea of “poisoning” the encrypted data before the data was transmitted. If intercepted in transit, the data itself could never be decrypted without knowing how it was poisoned and what was needed to “cleanse” it. And that would require access to either the API of the device doing the corruption or the cleansing, or else someone who knew the method. By using this method, all but physical and social vectors are nullified. And control of those vectors is an illusion. Bob S Sent from my iPhone > On Jun 24, 2022, at 13:22, Mark Wieder via use-livecode > wrote: > > On 6/24/22 10:04, Mark Waddingham via use-livecode wrote: > >> The only way to use these keys is from server scripts running on a server >> which you do your best to maintain the security of. Ideally these keys >> should be stored in files which are only readable by specific users - >> usually the web-server user which is running the backend scripts which needs >> to make the requests. > > Or as server environment variables retrieved only by server scripts which are > not user-accessible. > > -- > Mark Wieder > ahsoftw...@gmail.com > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: On API keys...
On 6/24/22 10:04, Mark Waddingham via use-livecode wrote: The only way to use these keys is from server scripts running on a server which you do your best to maintain the security of. Ideally these keys should be stored in files which are only readable by specific users - usually the web-server user which is running the backend scripts which needs to make the requests. Or as server environment variables retrieved only by server scripts which are not user-accessible. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: On API keys...
Mark, thanks for taking the time to give this in-depth answer. This will come in handy for others as well I am sure. Have a great weekend. Tom On Fri, Jun 24, 2022 at 1:04 PM Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > So this is mainly aimed at Tom Glod due to a question he asked in this > afternoon's Feature Focus session which I perhaps did not answer > particularly well (and given that it is security related, I figured I > should expand on what I said). > > The question was whether putting an API Key as a LiveCode 'constant', > rather than anything else, made it 'more secure' - the answer is 'no > more than putting it anywhere else in a password protected script'. > > However, what I should have probably expanded on is what my > understanding on the best practice for API keys in general is... > > I have come across three kinds of API key in practice: > >1) API keys intended to be used from web pages (in client-side code) > >2) API keys intended to be used in deployed apps > >3) API keys intended to be used for doing secure things > > How I would advise using them (based on my current understanding, at > least) is: > > TYPE 1 > > In (1) above you have things like Google Analytics 'product ids' (which > aren't strictly API keys I guess, but are similar enough to warrant > inclusion) and Google Maps JS keys. > > As these are intended to be used in client side JavaScript - there is > very little, if anything, you can do to protect them directly. > > For Analytics, since the worse that can happen is that someone can > generate fake analytics it doesn't really matter - and the data can be > relatively easily filtered and processed to eliminate any dodgy looking > submissions. > > For Maps, it can cost you money if someone else tries to use yours - > however, you can restrict the key by the referring website and IP > addresses, as well as what the key can do. > > TYPE 2 > > In (2) you have things like Google Maps App keys (for Android/iOS) - and > all manner of other 'cloud type' services which have (native) app > bindings for mobile (and desktop). > > Many services offer restrictions for these keys too - for example Google > Services API keys can be restricted by Android app signing hashes and > ids, and iOS app bundle ids. > > However, in general, these services generally suggest that you ensure > that the API key is not extractable directly from the app bundle (after > decompressing in general) - i.e. that the key be obfuscated in some > fashion and does not appear in plaintext. > > It is important to note that they do not require any more than this > because, at the end of the day, any API key has to be in memory at some > point, and indeed has to be transmitted 'over the wire'. If someone has > enough access to access memory, then they have enough access to > intercept the HTTP requests (even if encrypted - if they really know > what they are doing) so obfuscating in the on-disk files of the app is > as good as you can get. > > If these keys are compromised then it is a pain - it might cost you > money (as all these services which have them tend to charge by use) - > and, if embedded in an app, will require an app update to replace. > > TYPE 3 > > Certain services require (sometimes in the TOS!) that their API keys > *never* leave a secure bubble which you control - this means they must > never appear in deployed apps or in files transmitted to the browser. > Payment gateway API keys will pretty much always fall into this category > - Stripe is a good example. > > The only way to use these keys is from server scripts running on a > server which you do your best to maintain the security of. Ideally these > keys should be stored in files which are only readable by specific users > - usually the web-server user which is running the backend scripts which > needs to make the requests. > > Indeed, services which require this tend to design their APIs for the > intention of being used on a server. > > WHAT TO DO IN LIVECODE > > If you are dealing with a type 1 key then you really don't have to worry > - they are designed to be used in a context which offers zero ability to > protect them, so including them in a deployed app (in particular) is > more secure out of the gate than in their intended use in a webpage. > > [ Of course, whether you are actually *allowed* to use their services > from anything other than websites is another matter - and entirely > defined by their TOS - but I digress! ] > > If you are dealing with a type 2 key then the requirements put on their > use in deployed (native) apps is more than catered for by having the key > in script, in a pas
On API keys...
So this is mainly aimed at Tom Glod due to a question he asked in this afternoon's Feature Focus session which I perhaps did not answer particularly well (and given that it is security related, I figured I should expand on what I said). The question was whether putting an API Key as a LiveCode 'constant', rather than anything else, made it 'more secure' - the answer is 'no more than putting it anywhere else in a password protected script'. However, what I should have probably expanded on is what my understanding on the best practice for API keys in general is... I have come across three kinds of API key in practice: 1) API keys intended to be used from web pages (in client-side code) 2) API keys intended to be used in deployed apps 3) API keys intended to be used for doing secure things How I would advise using them (based on my current understanding, at least) is: TYPE 1 In (1) above you have things like Google Analytics 'product ids' (which aren't strictly API keys I guess, but are similar enough to warrant inclusion) and Google Maps JS keys. As these are intended to be used in client side JavaScript - there is very little, if anything, you can do to protect them directly. For Analytics, since the worse that can happen is that someone can generate fake analytics it doesn't really matter - and the data can be relatively easily filtered and processed to eliminate any dodgy looking submissions. For Maps, it can cost you money if someone else tries to use yours - however, you can restrict the key by the referring website and IP addresses, as well as what the key can do. TYPE 2 In (2) you have things like Google Maps App keys (for Android/iOS) - and all manner of other 'cloud type' services which have (native) app bindings for mobile (and desktop). Many services offer restrictions for these keys too - for example Google Services API keys can be restricted by Android app signing hashes and ids, and iOS app bundle ids. However, in general, these services generally suggest that you ensure that the API key is not extractable directly from the app bundle (after decompressing in general) - i.e. that the key be obfuscated in some fashion and does not appear in plaintext. It is important to note that they do not require any more than this because, at the end of the day, any API key has to be in memory at some point, and indeed has to be transmitted 'over the wire'. If someone has enough access to access memory, then they have enough access to intercept the HTTP requests (even if encrypted - if they really know what they are doing) so obfuscating in the on-disk files of the app is as good as you can get. If these keys are compromised then it is a pain - it might cost you money (as all these services which have them tend to charge by use) - and, if embedded in an app, will require an app update to replace. TYPE 3 Certain services require (sometimes in the TOS!) that their API keys *never* leave a secure bubble which you control - this means they must never appear in deployed apps or in files transmitted to the browser. Payment gateway API keys will pretty much always fall into this category - Stripe is a good example. The only way to use these keys is from server scripts running on a server which you do your best to maintain the security of. Ideally these keys should be stored in files which are only readable by specific users - usually the web-server user which is running the backend scripts which needs to make the requests. Indeed, services which require this tend to design their APIs for the intention of being used on a server. WHAT TO DO IN LIVECODE If you are dealing with a type 1 key then you really don't have to worry - they are designed to be used in a context which offers zero ability to protect them, so including them in a deployed app (in particular) is more secure out of the gate than in their intended use in a webpage. [ Of course, whether you are actually *allowed* to use their services from anything other than websites is another matter - and entirely defined by their TOS - but I digress! ] If you are dealing with a type 2 key then the requirements put on their use in deployed (native) apps is more than catered for by having the key in script, in a password protected stack - for example, as a constant return value of a function, or indeed as a constant defined in the script which is talking to the API. With this, the key will not appear in plaintext in any of the files included in the built app (even after the container is unzipped). [ I should note here that custom properties values also do not appear in plaintext in any of the files of a built app - however, having them in a password protected script offers an extra level of protection ]. If you are dealing with a type 3 key then you must only use that key via a server - this means you need to set up server side scripts which your app then talks
