Fog Creek Software
Discussion Board




Excel Add-in code security

How secure is the code in an Excel Add-in? Is there any way for the user to access the code or modify it in any way?

I'm testing some production code controls. While the client is using Excelto do some of their calculations  (separate issue that is getting them in trouble) , the more complex sensitive items are in an Add-In. I want to make sure that it isn't possible (within reason) to easily modify that.

Thanks!

J.P. Rhea
Tuesday, August 26, 2003

Are you concerned just about protecting users from making dumb changes, or about protecting trade secrets?

I believe there's an option in the VBA editor in Excel for setting password access to the code, and that should foil a simple attempts to view or change the code.  However, I don't know if that actually encrypts the code module on the disk -- if not, it would be possible to open it in Notepad to get at the code.

A more secure solution is to build the add-in using Visual Basic 6, and then compiling a DLL for distribution.  You can also use VB.Net, but that code's not particularly secure unless it obsfucated.

Robert Jacobson
Tuesday, August 26, 2003

It is not particularly secure after obfuscation either!

When you give software to customers you are giving them a machine that does some task on their behalf.  There is no technical way to stop them from taking that machine apart, understanding it and modifying it.

This is a human problem, not a technical problem.  There are lots of ways to stop your code from being reverse-engineered, and none of them have anything to do with properties of the code.  They have to do with relationships between human beings.  Some examples:

* only give the code to people you trust.  Make them promise to not reverse-engineer it and not to give the code to anyone less trustworthy.

* give the code to untrustworthy people.  Threaten to sue them if they reverse-engineer it.  Watch them carefully.

* change your business model so that reverse-engineering doesn't hurt you.  Then you can give the source code away.

* etc.

Eric

Eric Lippert
Tuesday, August 26, 2003

I'm not worried about reverse-engineering.

What is needed in this enviornment are production controls over changes to code. I don't want the user to be able to change the code. I could care less about viewing it.

I'm more familar with simple Excel Macros, but I don't understand how the Add-In architecture works and was wondering if that is secured in any way or if it is just another VBA module tacked onto the sheet or what.

Thanks for the feedback so far...

J.P. Rhea
Tuesday, August 26, 2003

If you're programming the add-in using Excel's VBA editor, it's visible to everyone (and modifiable by everyone) by default.  Just go to Tools: Macros: Visual Basic Editor to see it.  In the Project window, you should see one or more "Modules" (Visual Basic code modules) which you can click to view and change the code.

You can prevent this by assigning a password.  Right-click on the module, select VBA Project Properties, and the click the "Protection" tab.  That should be sufficient to prevent users from modifying the code. 

If I remember correctly, the modules can either be limited to a single Excel document (which are then saved with the document) or apply to all documents.  I think the later are stored in an Excel template file.

Check out this reference manual from Microsoft, particularly Chapter 2:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/html/deovroffice2000visualbasicprogrammersguide.asp?frame=true

Robert Jacobson
Tuesday, August 26, 2003

Everyone's answering a different question... security means many things.

In your case, you want tamper-resistance, you don't care about distribution or reverse-engineering.

Presumably you care about the results of the calculation?

The only way to really prove it is to re-do the calculations on your own--pick a few and verify.

On the client, the user could swap out the DLL with a similar DLL, or reverse-engineer and trap things, etc. If you have control over the client, you can reduce the chance of this happening in various ways. You could have a monitor program on the client verify that the DLL being loaded by Excel is your DLL, etc. You may be able to lock down the registry and filesystem so the user isn't really able to move files around, etc.

I doubt the add-in interface is designed for tamper-resistance, the user is trusted. Again, if you don't trust them, verify their work with some code you do trust and have full control over.

mb
Tuesday, August 26, 2003

The password protection in the VBA environment will stop a casual user from monkeying with your code.  However, there are applications and even services out there that will figure out or remove the password, so the code is not very well protected against other developers that are determined to steal or view your work.

If you need a better protection scheme, consider putting the significant portion of your work into DLL's of some sort and limiting the addin code to stub functions that call the relevent DLL methods.

Ran Whittle
Wednesday, August 27, 2003

*  Recent Topics

*  Fog Creek Home