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