How do you protect proprietary Studies/Formulas

[nrogers805]

How do you add a password and protect or hide the code of a proprietary study or formula??

Also, is it possible to add an expiry date so that the study would be unusable after expiry??

[dloomis]

Re: Reply to post 'How do you protect proprietary Studies/Formulas '

Did you try Tools, Encrypt/Decrypt?

----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Monday, December 23, 2002 10:24 AM
Subject: Reply to post 'How do you protect proprietary Studies/Formulas '


> Hello dloomis,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

[mattgundersen]

Re: Reply to post 'How do you protect proprietary Studies/Formulas '

Hi nrogers805,

I see Dave Loomis responded with the encrypt/decrypt which will allow you to
password protect and encrypt your code.

You can also set an expiry date for your formula. To do that, go into your
/formulas/other folder and look @ the ExpiredFormula.efs

m.

--- [email protected] wrote:
> Hello mattgundersen,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

[nrogers805]

Thanks guys

[nrogers805]

Is there a way to protect the formula so that it can only be run on the PC that it was installed on?

Or, is there any other way of preventing 'copies' being made?

[gspiker]

There is no way of doing that, however, if you encrypt the file and use a one month (or so) time expir. then someone would have to not only steal the .efs file, but have to know how to unencrypt it to modify the expir. date to allow it to keep running.

[nrogers805]

Is it possible somebody could unencrypt a formula?

What about the use of DLL's, couldn't they be used in some way to build extra security for the formula??

[gspiker]

Hi,

I was hoping Matt, Dion, Jason or someone from eSignal would comment on this, but as they haven't, I'll give you my take.

If you efs is created such that it needs a .dll to run (ie: looks for some kind of return from it), the obviously your .dll can do anything it wants to generate that return. Things like examining the registry file, demanding some input from the user each time it is run, etc...

However, the problem is that if I can decrypt the efs file, then I will know what the .dll needs to return to execure and I can fake it out.

There may be some way to use .dll to implemet extra security, but any methods I can think of off the top of my head would all be moot if the base efs code is readable.

Maybe Matt or someone can comment on the type of encyption used, number of bits used, etc. That may make you feel safer.

[mattgundersen]

Here's an idea...

This does not exist - YET

Is there a way to protect the formula so that it can only be run on the PC that it was installed on? Or, is there any other way of preventing 'copies' being made?

What if... we added a function go EFS "getUserName()". This would return the name of the user logged in. From that, you could add *something like* this to your EFS:

var un = getUserName();
function isValidUser() {
   if(un == "USERNAME")
        return true;
    return false;
}

function main() {
    if(!isValidUser())
        return;


    // else... do your thing...
} 

The idea is that you could protect your formula by only allowing certain users to run the formula. You then encrypt the formula and can make it publicly available. Although this doesn't limit what PC's it runs on, it does limit WHO can run it.

m.

[mattgundersen]

oK, it's done...

7.2 will have a new EFS function: getUserName()

m.

[gspiker]

Matt,

While a good idea, it still doesn't address the issue of "how secure" is the encryption used. If it isn't very secure, then the feature will not help.