And it's equally trivial to "recover" a password on most Microsoft Access databases with Access PassView: http://www.nirsoft.net/utils/accesspv.html

While some would argue that any "security" is better than no security, I would disagree. Making a user believe that there is security when it is trivial to break it is worse than no security at all.

The locks on most front doors are trivial to break with a bump key set: http://www.lockpicks.com/professionalbumpkeyset30-keysv30.as...

Some security is better than none, it deters crimes of opportunity and the casual thief. As with anything else if you want real security you need to do your research and make the proper investment.

This protection, though, is less like the lock on a house, and more like the lock on a diary. You might not be able to break it right away, but you can just stuff it in your bag and break it later at your leisure. Crimes of opportunity are only dissuaded when the opportunity eventually ends.

Kudos for the comparison to breaking the lock on a diary. Those are pretty much pointless, as are these.

In the MDB format used in Access 2003 and older. BTW the user-level security and what was called "encryption" that was also supported in MDB format is no better. This encryption (which was based on 32-bit RC4) was so weak it was renamed "encoding" in Access 2003. All of these was ditched with the Access 2007 ACCDB format and replaced with real encryption based on CryptoAPI RC4 encryption (as termed is MS-OFFCRYPTO) introduced in Office XP (they did not adopt the new encryption introduced in Office 2007 file formats until Access 2010).

Any encryption method we come up with today can be considered "encoding" in the future, given enough time.

Except possibly AES.

http://security.stackexchange.com/a/25392

Excel does implement some 40-bit RC4 encryption method for workbooks that require a password to read (which you can brute force within a day), but the password to modify is trivial to remove.

By default in the old XLS file formats. Office XP introduced CryptoAPI RC4 encryption to improve security, unfortunately the UI for it was removed in Office 2007 and you will have to use the DefaultEncryption registry key to enable it now.

While leading the user to think they are more secure than they are is definitely a bad thing, you are right there. If we are honest about the level of security offered (a message to the effect that "this will only deter opportunistic viewers, for full security please use a proper encryption method" - or how ever you'd word that for the man-on-the-street)then user will either find an alternative or decide it is worth while (or decide they don't care).

One thing that makes this "security" better than no security at all is that the reader has to purposefully takes steps to read the content so they can't try use any sort of "I saw that information accidentally" defence if called to task about knowing something they shouldn't (or passing that information on to someone else).

Officer, arrest this man, he removed copy protection that was useless and didn't do anything!

Also, Outlook 2003¹ PST files, also when created with the "strong encryption" option, are no more then obfuscation. libpst convert them to MH with no worries.

[1] Not that updated, I know, but I do not use Outlook since then.

AFAIK the newer versions of Outlook still use the same format. And the PST password is just as useless too.

I wonder though, if circumventing such protections would still violate the DMCA or trade secret law? (The value of such protections varying with the nature of the VBA content of course.)

Surprise?