I am going to distribute an add in within my departament. Because I want to make it safe I would like to ask about some best practices in this matter. I have read the Microsoft articles about that, but I would also like to ask about Your experience. Do You think password is enough security? The addin will be stored in a shared drive, it will be read only.
-
What do you want to make it "safe" from? Are you concerned about people modifying the code? Are you concerned the .XLAM will escape into the wild and someone will have access to proprietary information? Are there passwords embedded in the code that someone could gain access to? – FreeMan Jun 18 '18 at 18:43
-
I want to make it safe from any modification from other users or, some malicious macro/code/everything what can corrup my code. I am new to the vba so I think asking questions to more experienced developers is a good idea. Microsoft documents provide lots of informations but they dont replace knowledge of experienced developers. Oh, one more thing, I am not afraid that my code will run into the wild... – tomek198823 Jun 19 '18 at 18:53
1 Answers
VBA code is not secure, full stop. Put the file on a network share where IT can control who has read/write access.
Anything you do to "make the VBA code secure" will be defeated within seconds by anyone that wants to "get in": putting a password on the VBA code is about as secure as locking your screen door - it keeps the bugs out, but if that's the best you've got any burglar is going to pee their pants in laughter as they cut through the screen like a hot knife in butter.
By putting the file on a network share, and having Active Directory (assuming you're on an AD domain) manage users & groups access (i.e. who is authorized to read & who is authorized to write in that network share), you put it on the IT infrastructure to manage authentication and authorizations, instead of putting a giant padlock on a screen door.

- 69,817
- 8
- 107
- 235
-
Thanks for advice. I am going to talk with IT guys about authirizations and other stuff. – tomek198823 Jun 19 '18 at 19:05
-
@tomek198823 to be fair there are a number of (paid) 3rd-party obfuscation tools that *can* severly hinder one's ability to "crack open" a VBA project, but IMO they're all overkill and toy with internals in a way that essentially corrupts the file, making it effectively *run-only*. e.g. Unviewable++ is somewhat recoverable; then there's stuff like [Secure++](https://www.spreadsheet1.com/secure-vba-compiler-for-microsoft-office-excel.html) which effectively removes all the code, leaving only the compiled p-code in the file, but even p-code can be decompiled, so... – Mathieu Guindon Jun 19 '18 at 19:10