Internal security of Rev?

John Tregea john at debraneys.com
Wed Jul 12 04:27:23 EDT 2006


Dear Richard,

Thanks for your post. Yes my original question was about protecting 
classified information within a database where the front end may end up 
being Rev based.

My concern was whether the stand alone application (once built) could be 
disassembled in any way that would reveal some of the structure of the 
back end of the system. For example;

I plan to base64encode a user name and password for PostgreSQL and store 
each element in its own custom property in the main Rev stack.

Would it be possible for someone to read the scripts in the built 
application, run a base64decode on my two custom properties, and...
go do skull duggery in the database?

I realise I could tie the front end closer to the DB and create a 
legitimate account in PostgreSQL when an administrator sets up a new 
user account and password, but the administrator needs an account and 
password to do that and the db structure itself is confidential to our 
company.

You may have heard of the US "Container Security Initiate" and 
"Customs-Trade Partnership against Terrorism", the World Customs 
Organisations "Framework for Supply chain Security" or the International 
Maritime Organisations "International Ship and Port Facility Security 
Code"? Well we are building a front end (hopefully in rev) and a secure 
database for the risk assessments, operational compliance needs and 
documentation requirements of all the above...

The network communications would use SSL 128 bit encryption, the data in 
the database is encrypted (by revolution) using Blowfish, there will be 
a biometric thumb print scanner built into the keyboard, the application 
would only reside on a U3 Drive, the database will be on a dedicated 
Solaris 10 CPU with a hot swappable HD that would be removed when the 
operator is not present etc. etc. etc.

But the structure of the stand alone rev application is my remaining 
concern. (unless you all think of some stuff I haven't thought of.)

The classified information would specifically be for supply chain risk 
assessments under ISO 28000 and 28001. We hope to use Rev to build a 
front end to a proprietary database structure, but have to know we can 
certify the resulting application under ISO 17799 (Information Security 
Management) before clients would be prepared to use the product/service.

The branch of the thread about protecting the software is of interest 
too, but mainly because my boss would be very un... happy if I allow the 
results of years of research and development to be hacked when we 
release the software.

Having said all this I will now have to find and eliminate everyone that 
reads this email... ;-)

Regards

John T.

Richard Gaskin wrote:
> John Tregea wrote:
>
>> I read about MD5 but thought it was a way of generating a hash string 
>> and using that string to check if the originating string had changed. 
>> Do you mean I could "un" MD5 a string like base64Decode?
>
> MD5 is used to create a "signature" of a chunk of data which is 
> mathematically improbable to have been derived by a different chunk. 
> This is useful for comparing two things when you don't have the things 
> themselves, such as passwords, but the MD5 result doesn't contain 
> enough data to derive its source.
>
> However one can use it in place of a password, so you can compare 
> password results without ever embedding the password itself.
>
> This extremely lightweight encryption function uses MD5 for that purpose:
> <http://www.revjournal.com/tutorials/handy-handlers-005.html>
>
> While that particular function is at the "toy" level of security, 
> stronger methods could be made which use MD5 in related ways.
>
> But all of this seems a red herring, if I've read this thread 
> correctly.  At first I had the impression we were talking about 
> protecting critical data, but in later posts it seems we're just 
> talking about anti-piracy.
>
> With all due respect, the best investment of your time with regard to 
> anti-piracy is to ignore it altogether and put the time into features, 
> marketing, and offering world-class support.  Pirates are rarely in 
> the intersection of potential customers, so fighting them is a 
> business distraction.
>
> -- 
>  Richard Gaskin
>  Managing Editor, revJournal
>  _______________________________________________________
>  Rev tips, tutorials and more: http://www.revJournal.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>



More information about the use-livecode mailing list