Standalone Application Security

[Warren Kuhl]

Richard,

Thank you very much for the explanation!  This really puts my mind at ease.
I will make sure to password protect my application.  Since I am not storing
nuclear secrets...I will just to my best to encrypt as you have outlined
below.

Appreciate your response,

Warren

On Thu, Mar 31, 2011 at 9:32 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:

>  Warren Kuhl wrote:
>
>> I have a application that I am rolling out shortly.  The stack includes a
>> key to access an excrpyted Valentina DB.  From what I read with other
>> posts
>> on the list, RunRev applications are not that hard to decrypt?  If this is
>> the case, what are the best pays to protect myself from having someone
>> to "break down" the Runrev application to get the key to decrypt the
>> database?
>>
>
> Stacks can be protected with a password property (settable at build time in
> the Standalone Builder or at any time using the Message Box).  This will
> make scripts in accessible in the IDE, and will make both scripts and custom
> props unreadable on disk.
>
> In older versions (pre-4.0?) the encryption scheme was described by Scott
> Raney as a derivative of DES -- more than enough to keep out script
> kiddiesm, but only about a weekend's work for a professional cracker.
>
> In more recent versions scripts are protected with a much stronger algo
> (triple DES?) and are considered much more secure.
>
> In the saved stack file not only are your scripts encrypted but also custom
> props are no longer readable in a binary editor.  However, keep in mind that
> those properties will still be available in unencrypted form in any LiveCode
> editor.
>
> That should only be a concern for data stored in custom props within stack
> files other than the standalone, since the new standalone format makes
> extracting the stack file from the executable much more difficult than it
> used to be.
>
> You can hard-wired things like passwords into scripts to have them
> protected, or for larger or more complex data store them in custom props
> after running them through LC's encryption functions (which offer Blowfish
> and other good options).
>
> If your stack involved nuclear secrets or other similarly critical
> information, note that no code is ever truly safe from the
> sufficiently-motivated cracker.  Low-level debuggers can disassemble any
> code written in any language to derive both algos and data at runtime, no
> matter how secure the storage format is.  Anything that can be run can be
> disassembled.  Obfuscation can slow them down, but nothing can stop a
> skilled cracker from learning the inner secrets of any app.
>
> If you were dealing with data or algos that critical, controlling physical
> access to the application is the only way to minimize risk (and as the
> Pentagon's showed us, with random USB thumb drives staff mindlessly inserted
> into systems at CENTCOM and the occasional briefcase left in a hotel
> restaurant, even attempting to control physical access is not without risk).
>  As they say in the security forums, "physical access = root".
>
> --
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com<http://www.livecodejournal.com/>
>  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv<http://livecodejournal.com/blog.irv>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>