(Note: Let's "critically evaluate" the password protection feature for VBA Projects. We do not discuss "Techniques to break a password" here.
Also, let's restrict our scope to VBA projects.)


VBA Project protection:
===============
- In VBE, there is a feature to password protect your VBA project.
- In order to view the code and Userforms of a password-protected project, you need a password.

Also, Let's compare the VBA Project-Protection with the file-open password feature of an Office document, such as Word or Excel file.

Word, Excel file-open password:
====================
- With password "breakers", an average password of 7 or more characters takes ages to break by Brute-Force techniques.
- In order to open a file, you need to know the actual password. If a password is "hello", you need "hello" to unlock it.

VBA Project password:
===============
- No matter how long a password is, it takes less than 0.5 seconds to find out the password.
- Most VBA Project passwords have a 4-character "equivalent". It means, you set a 25 characters password, and someone can open it with a 4-character password.


Other Info:
=======
- The "History" of Word, Excel file-open password protection is longer than the VBA Project password protection.
- There should be no convincing arguement to say value of VBA code in a file is lower than the text or numbers in a file. Therefore, there is no convincing arguement to say that "VBA Projects deserve to be less securely protected".



Let's talk about this.
Welcome anybody's idea, welcome especially someone in Microsoft.

A Microsoft representative, for example, can tell us:
- how you did the functional specifications for that function;
- was the person who designed that function been fired or anyone should be held responsible for the w-r-o-n-g design?
- who decided to continue to adopt the wrong design? Who is responsible for this? (this is different from the point above.)
- tell us some names. (We deserve to know the names, as, for example, if you were killed you want to know who killed you.)
- Any escalation procedure for problems?
If "negative" for points 2, 3, 5 above, Microsoft, you have a lack of controls in your software development operations, and either your Group Internal Audit department or your auditors should be replaced.

hmm..
it's worse than you think...

Workbook and Worksheet protection encrypt the stored data.
(Although the encryption algoritm for worksheet is absurdly weak)

VBA project protection does NOT encrypt the data, it merely prevents access
to it. Even if it had a strong algoritm:

As long as you dont use workbook protection (which DOES encrypt all contents
of the file), then the modules' data is saved in plain text and can by read
from the file with any hex editor, regardless of VBA password.



keepITcool

< email : keepitcool chello nl (with @ and .)
< homepage: http://members.chello.nl/keepitcool


?B?RWR3aW4gVGFtIChNUyBNVlAp?= wrote:

(Note: Let's "critically evaluate" the password protection feature for
VBA Projects. We do not discuss "Techniques to break a password" here.
Also, let's restrict our scope to VBA projects.)



Let's talk about this.
Welcome anybody's idea, welcome especially someone in Microsoft.

There should be no convincing arguement to say value of VBA code in a file
is lower than the text or numbers in a file.

The lower level of protection is not a value judgment on workbook data
versus code. A workbook/sheet and its VB code has to work without the user
supplying the password once the workbook is opened. Therefore it cannot be
encrypted. The same restriction does not apply to workbook open protection.

--
Jim Rech
Excel MVP