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 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 sh
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
Re: {OT} Are there any ffmpeg "experts" on this list?
On 2022-06-24 17:05, Paul Dupuis via use-livecode wrote: I was unaware of the mediaFoundation library - I had thought that we'd not see support under LiveCode 10 switches from DirectShow to MediaFoundation. Its actually been buried in the product (business/pro features) for a long time - I had forgotten about it until relatively recently... That said, our application is macOS and Windows and the appeal of ffmpeg via shell is that the same code will work across platforms for us. FWIW, I *think* mergAV can do similar things on macOS* to the mediafoundation external on Windows - although the APIs, while similar, do require different code. However, if you are using ffmpeg for things other than concatenating tracks/movies (i.e. the features those libraries provide) then the separate code needed wouldn't be worth it to save inclusion of ffmpeg. Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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: {OT} Are there any ffmpeg "experts" on this list?
Panos, Thank you! I was unaware of the mediaFoundation library - I had thought that we'd not see support under LiveCode 10 switches from DirectShow to MediaFoundation. That said, our application is macOS and Windows and the appeal of ffmpeg via shell is that the same code will work across platforms for us. Still, for other projects, I'm very happy to have been made aware of the mediaFoundation library! On 6/24/2022 11:27 AM, panagiotis m via use-livecode wrote: Hello Paul Not a ffmpeg expert, but have you seen the mediaFoundation library? See the dictionary entry for "mediaFoundationTranscode" - it has a detailed example for concatenating 2 media files. Hope this helps Kind regards, Panos -- On Fri, 24 Jun 2022 at 18:08, Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> wrote: I am doing some work with Livecode script constructing calls (via shell()) to ffmpeg to perform some video/audio concatenation. I have barely learned a tiny bit of ffmpeg and and wondering if there are any people proficient with ffmpeg wh might be interesting in a small bit of paid consulting to help with ffmpeg command line syntax for various operations? If interested, please email me directly. ___ 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: {OT} Are there any ffmpeg "experts" on this list?
In one of my projects i do use ffmpeg for some audio conversion and id3 tag handling. For me the tool ff-Works (https://ffworks.net) helped me a lot. Normally its a GUI for ffmpeg, but the good thing is the user is also able to see the command line that was used for a task. So in case no one other jumps in and if you are on Mac maybe this tool is also of help for you, i Regards, Matthias > Am 24.06.2022 um 17:07 schrieb Paul Dupuis via use-livecode > : > > I am doing some work with Livecode script constructing calls (via shell()) to > ffmpeg to perform some video/audio concatenation. > > I have barely learned a tiny bit of ffmpeg and and wondering if there are any > people proficient with ffmpeg wh might be interesting in a small bit of paid > consulting to help with ffmpeg command line syntax for various operations? > > If interested, please email me directly. > > > ___ > 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: {OT} Are there any ffmpeg "experts" on this list?
Hello Paul Not a ffmpeg expert, but have you seen the mediaFoundation library? See the dictionary entry for "mediaFoundationTranscode" - it has a detailed example for concatenating 2 media files. Hope this helps Kind regards, Panos -- On Fri, 24 Jun 2022 at 18:08, Paul Dupuis via use-livecode < use-livecode@lists.runrev.com> wrote: > I am doing some work with Livecode script constructing calls (via > shell()) to ffmpeg to perform some video/audio concatenation. > > I have barely learned a tiny bit of ffmpeg and and wondering if there > are any people proficient with ffmpeg wh might be interesting in a small > bit of paid consulting to help with ffmpeg command line syntax for > various operations? > > If interested, please email me directly. > > > ___ > 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
{OT} Are there any ffmpeg "experts" on this list?
I am doing some work with Livecode script constructing calls (via shell()) to ffmpeg to perform some video/audio concatenation. I have barely learned a tiny bit of ffmpeg and and wondering if there are any people proficient with ffmpeg wh might be interesting in a small bit of paid consulting to help with ffmpeg command line syntax for various operations? If interested, please email me directly. ___ 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
