How to improve protection on a MS Access MDB besides password protection?

Question

Hi guys, i have a mdb access which is password protected but that can be easily cracked by a free tool found in google within like 1second. Besides paying for some expensive tools, is there a good way in how to protect a ms access databse file? I'm thinking of encrypting it then via a dll to decrypt it, get some data, and pass it to a third party app, then when the connection is close, encrypt the file again.

If anybody care to comment on the fallacy of this method, or has some other resources, tools, etc, that would be great.

thanks :)

Answer 1

Saving the data in an encrypted format would be a solution. If the password "fails" the cracker has to decrypt the data as well

Answer 2

Access is an old database, why not SQL Express 2005 (witch is for free)? you will get plenty more about security and inside your application you use a user/pwd in the connection that no one will know and can't see it... if they try to open SQL, they will only see the Database Name, and nothing else (remember to use SQL authentication and not windows authentication)

if you are using .NET, in your Setup you can tell to only install your application after SQL 2005 Express is installed, or if using other language, use InstallShield, FinalBuilder, etc. to do the same...

:)

you idea "struggles" me when I thing that... Access has start to have poor response time with more than 30k rows in one table (quote from Microsoft), and if you going to create a Layer to encrypt / decrypt data ... your app will just go from slow to not working at all ... will this be a good idea?

Answer 3

Whatever method you use will be crackable by someone knowledgeable.

It really depends how valuable the data is: if it's truly valuable, I'd use a different model, like putting the database behind a server on the internet. Then you can limit the number of queries, as well as filter for misuse.

If a leak can be traced, or is of limited use, you're better off guarding the data with the licensing agreement. At least then you may have a way of recovering your losses. Note that the OED has recently removed its copy protection.

Also consider the future: some network admin in 10 years may need to legitimately get access to the data, and using a simple password will show the data should be protected, but still allow circumvention.

Answer 4

What about updating from MDB format to ACCDB (Access2007) format?

Get started with Access 2007 security

"The encryption tool in Office Access 2007 combines and improves on two older tools — database passwords and encoding. When you use a database password to encrypt a database, you make all data unreadable by other tools, and you force users to enter a password to use the database. The encryption applied in Access 2007 uses a stronger algorithm than was used in earlier versions of Access..."

Answer 5

For a desktop app I would suggest you go the route of Sql Server Compact Edtition (SQLCE). Or if you have a bit of money, VistaDB (unlike SQLCE it supports stored procedures, views and triggers). You'll get better security, better performance, less hassles with maintenance and corruption and easier deployment.

Answer 6

I'm unclear from reading your post if you are only trying to protect data, or if you are you trying to protect something else such as say VBA code exclusively. You say that you have an mdb file but are you working with Access 2003, 2007 or some other version? Have you/are you planning to deploy your Access solution on an Intranet site? (For my comments below I am going to assume that you are).

I agree with other posters that if you have the chance to consider other solutions before deploying an Access-based solution you should. However, if you can't avoid an Access-base solution I would like to share the following suggestions and/or comments.

1. If you are working with Access 2003 then you may want to consider User and Group Level security (User/Group Level security setup & configuration not available in Access 2007 (accdb) format databases, however Access 2007 will recognize User/Group permissions from mdb files. With User/Group level security you can limit access to your database based on defined users and workgroups. For more information - [http://office.microsoft.com/en-us/access/HP051882261033.aspx][1]

2. Consider splitting your database (keep your data separate from your application objects such as Forms, Reports) and/or creating different versions that limit the objects that are available.

3. Keep a master for design and a replica for production. This is in keeping with the previous comment where the idea is that not everything is on the table for the taking. You may want to look into Access Developer Extensions (if you haven't already) which is available for 2003 and 2007 (free to download and install from Microsoft).

4. Employ, whenever possible, policies that discourage and/or limit staff or coworker access (again I'm assuming you're deploying on a company Intranet)

5. Encode your database. This will make property information for your tables, VBA code harder to retrieve as the database will be compacted and any design-level information will be removed or harder to access.

6. Lastly, if you have the time, resources and/or a nearby library/bookstore with a copy available I recommend that you check out Alison Balter's mastering Microsoft Office Access 2003, Check out the section on Developing Mult-User and Enterprise Applications which has a section on security. Updated for ACCESS 2007: Alison Balter's Mastering Microsoft® Office Access 2007 Development

Answer 7

I'm all for using Jet wherever it's appropriate, but when you start worrying about password protecting data beyond what you would get with NTFS security and Jet ULS, you're in territory where you need to use a different data store.

But let me say this:

Security is not a technological problem -- it's a people problem. No security will protect you from the user with admin permissions who wishes you ill. You always have to trust people enough to give them permissions to view and edit your data. Too often, the emphasis is on how to keep the unauthorized users out of your data instead of on designing your app to protect your data from damage that can be done by the authorized users. The former is pretty easy, while the latter requires really careful attention not just to your security settings but to the way in which you design your app.

And in the end, you have to trust people to behave responsibly, and there's nothing Jet or SQL Server can do to help you with that.