Solved Best way to protect VBA code in Excel

[Mylton]

Hi everyone,



I’m looking for an effective way to protect my VBA code in Excel and prevent unauthorized access or copying. I know Excel has a built-in password protection option, but I’m looking for something more secure.



Does anyone have any recommendations for specific tools, advanced methods, or tutorials on this topic? What would be the best approach?



I appreciate any help!

 

[arnelgp]

there is a commercial software, but have not tried it:

VBA Code Protection and Compilation - XLS Padlock

Protect Excel VBA code with XLS Padlock. Use our VBA compiler to turn your sensitive VBA code into bytecode to stop copying or spying

www.xlspadlock.com

 

[Mylton]

Thanks for the tip. I’ll take a look and wait for any further help from the forum friends.

 

[Mylton]

* Thanks for the tip. I’will take a look and wait for any further help from the forum friends.

 

[Isaac]

Hi everyone,



I’m looking for an effective way to protect my VBA code in Excel and prevent unauthorized access or copying. I know Excel has a built-in password protection option, but I’m looking for something more secure.



Does anyone have any recommendations for specific tools, advanced methods, or tutorials on this topic? What would be the best approach?



I appreciate any help!

I have heard - note, am not myself positive but have heard - that the VBA project's password protection is one of the stronger ones, out of the various places 'passwords' can be set in Office (password to open word doc, password to protect workbook or worksheet in Excel, etc)

 

[Mylton]

Well... from what little I know...

The VBA password (Visual Basic for Applications) used to protect projects in Excel and other Microsoft Office applications is not considered a robust form of security for several reasons:

Weak encryption: Older versions of VBA use weak encryption, making it relatively easy for someone with technical knowledge to crack the password. Even in more recent versions of Office, the protection is not foolproof.

Simple cracking methods: There are widely available tools, often free or inexpensive, that can be used to remove or break VBA project passwords. These tools exploit known vulnerabilities in the protection process.

Password storage: The password is stored in a way that can be recovered with some reverse engineering. This means that if someone knows where to look, it may be possible to find the password directly or through brute-force tools.

No strong authentication: The VBA protection does not require advanced authentication methods (such as two-factor authentication), making the password more vulnerable to simple guessing attacks or automated brute-force attacks.

Lack of monitoring and logs: Unlike more advanced security systems, VBA protection lacks features like monitoring access attempts or activity logs, which would help detect attacks or password-cracking attempts.

Dependence on a single layer of security: The VBA password is essentially the only layer of protection, with no redundancy or backup. This makes it more prone to failure, especially when compared to more complex protection systems.

That's why I'm seeking ways with you to improve this.

 

[Isaac]

Well... from what little I know...

The VBA password (Visual Basic for Applications) used to protect projects in Excel and other Microsoft Office applications is not considered a robust form of security for several reasons:

Weak encryption: Older versions of VBA use weak encryption, making it relatively easy for someone with technical knowledge to crack the password. Even in more recent versions of Office, the protection is not foolproof.

Simple cracking methods: There are widely available tools, often free or inexpensive, that can be used to remove or break VBA project passwords. These tools exploit known vulnerabilities in the protection process.

Password storage: The password is stored in a way that can be recovered with some reverse engineering. This means that if someone knows where to look, it may be possible to find the password directly or through brute-force tools.

No strong authentication: The VBA protection does not require advanced authentication methods (such as two-factor authentication), making the password more vulnerable to simple guessing attacks or automated brute-force attacks.

Lack of monitoring and logs: Unlike more advanced security systems, VBA protection lacks features like monitoring access attempts or activity logs, which would help detect attacks or password-cracking attempts.

Dependence on a single layer of security: The VBA password is essentially the only layer of protection, with no redundancy or backup. This makes it more prone to failure, especially when compared to more complex protection systems.

That's why I'm seeking ways with you to improve this.

I don't think there is any other way to protect your code, short of leaving VBA altogether and making an app in .Net or something....or making an add-in that's COM exposed and can be used in your vba code, thus people can see your vba code maybe, but they cannot see the inner workings/guts of the add-in being referenced - Not sure about all of that exactly but I don't think there's any special way whatsoever you can password protect your vba code other than the built in feature.

Try to avoid storing passwords and other confidential information in code if possible - although I've never found the "other confidential information" very possible to avoid.

 

[Edgar_]

there is a commercial software, but have not tried it:

I don't recommend it. When I tried it, the software crashed a lot and when it "worked", the work wasn't protected anyway. I don't know if they fixed the multiple issues it had.

I've had success making an Add-In with VSTO. The distribution of the solution is convenient and it protects your work very well. It can be done with VB.NET or C#. Very reliable.

 

[isladogs]

There is a thread on LinkedIn that you might find of interest

Patryk Samborski on LinkedIn: Alternative Way To Protect VBA Code 🔒 No extra software needed: 1… | 34 comments

Alternative Way To Protect VBA Code 🔒 No extra software needed: 1. Protect code with a password (as usual) 2. Save and close the file 3. Rename .XLSM ->… | 34 comments on LinkedIn

www.linkedin.com

However your comments from post #6 still apply

 

[Mylton]

There is a thread on LinkedIn that you might find of interest

Patryk Samborski on LinkedIn: Alternative Way To Protect VBA Code 🔒 No extra software needed: 1… | 34 comments

Alternative Way To Protect VBA Code 🔒 No extra software needed: 1. Protect code with a password (as usual) 2. Save and close the file 3. Rename .XLSM ->… | 34 comments on LinkedIn

www.linkedin.com

However your comments from post #6 still apply

IslaDogs…
I saw your tip and was thinking here…
Is that what happens???


What happens when someone tries to reverse the changes made?
1. What you did: By replacing the sequence after CMG= (for example, CMG=abdcrft) with CMG=FFFFFFF, you essentially removed the protection or password from the VBA code, making it inaccessible. Excel will attempt to interpret this modified sequence as invalid or corrupted, which prevents access to the VBA code.
2. What someone else can do:
• If someone knows that you made this modification and tries to replace “FFFFFFF” back with the original sequence (e.g., abdcrft), yes, this could work, but only if the original sequence you used is exactly the same as it was before. Excel will expect this exact sequence to access the VBA code again.
• If the person inputs any other random value that is not the original sequence, Excel will not be able to properly validate the information, and the VBA code will remain inaccessible. In this case, the modification you made will still be valid, and the code will remain inaccessible.

Why does it need to be exactly the original sequence?
• The protection of a VBA project is managed by specific binary data. If you changed a character sequence, Excel likely stores this data in a specific form and expects the data to be correct to allow access to the code.
• If someone tries to restore a “password” or marker (such as “abdcrft”) but uses different characters, Excel will not recognize this data as valid. For example, if someone replaces it with a sequence like “abcxyz” (which wasn’t the original), Excel will see it as a corrupted sequence, and the VBA code will remain inaccessible.

Summary of what happens:
• If the person knows the exact original sequence (the one replaced by “FFFFFFF”), they may attempt to restore it.
• If the person doesn’t know the exact original sequence and tries to put any other character sequence, it won’t work. The code will remain inaccessible because Excel will not be able to validate or access the structure that depends on that exact sequence of data.

In other words, the change needs to be precise: the person must know exactly what the original characters were to restore the project. If they don’t, the modification you made (such as replacing it with “FFFFFFF”) will still protect the VBA code, keeping it inaccessible.


Follow the text. and it seems to me that it works.


I put a sample here so you can give your opinion.

Which I would be very grateful for.

Just another doubt.....
Does it work on a spreadsheet built for MAC?

 

[Mylton]

detail... this spreadsheet was zipped so that it could be attached here. I think that to test it you should unzip it and then yes... carry out the valuable tip you gave.
sorry for the writing. I'm using a translator.

 

[isladogs]

The tip wasn't mine though I have used it in the past for testing purposes
As another post in that LinkedIn thread makes clear, this form of unviewable protection is not difficult to reverse.
If security is important, you should NEVER rely on any one method of protection such as this.

One Excel security issue for me is that, as far as I am aware, there isn't a secure method of hiding worksheets.
They can be locked or hidden but password protection doesn't apply to hidden worksheets. Click Unhide and anyone can restore them

EDIT: no idea re Excel for Mac as I don't ever use that

 

[Mylton]

I understood. But is my line of reasoning wrong? If not... even if the person didn't know what the original CMG code they were from could they see the codes again? As for the spreadsheets themselves... if you block the view by VBA, would you still be able to do so?

 

[Gasman]

The tip wasn't mine though I have used it in the past for testing purposes
As another post in that LinkedIn thread makes clear, this form of unviewable protection is not difficult to reverse.
If security is important, you should NEVER rely on any one method of protection such as this.

One Excel security issue for me is that, as far as I am aware, there isn't a secure method of hiding worksheets.
They can be locked or hidden but password protection doesn't apply to hidden worksheets. Click Unhide and anyone can restore them

EDIT: no idea re Excel for Mac as I don't ever use that

Colin, someone posted a while back that there is a deep hidden property, that does not allow unhide. Not sure if it was here TBH though.



Actually VeryHidden.

Hide sheets and use xlVeryHidden constant in a macro - Microsoft 365 Apps

Describes that how to hide sheets and use xlVeryHidden constant in a macro.

learn.microsoft.com

 

[isladogs]

Thanks @Gasman.
I’ve seen this article before but had forgotten about xlVeryHidden.
That does help with security. Unfortunately there is also a weakness. If the worksheet contains any code it will be listed in the VBE. This gives the worksheet name so its trivial to then set it visible again.

 

[isladogs]

I understood. But is my line of reasoning wrong? If not... even if the person didn't know what the original CMG code they were from could they see the codes again? As for the spreadsheets themselves... if you block the view by VBA, would you still be able to do so?

Your basic reasoning is correct in theory. In practice, it can be circumvented without knowing the original code.

 

[Mylton]

Thank you

 

[isladogs]

Like this!

 

[Mylton]

Like this!

View attachment 118557

Wow.....

 

[isladogs]

Responding to your DM . . .