How to improve protection in MS Access MDB besides password protection?
I have access to mdb, which is password protected, but which can be easily hacked with a free tool found on Google within 1 second. Apart from paying for some expensive tools, is there a good way to secure the ms access database file? I'm going to encrypt it, then through a dll to decrypt it, get some data and pass it on to a third party application, and then when the connection is close, re-encrypt the file.
If anyone wants to comment on the fallacy of this method or some other resources, tools, etc., that would be great.
thanks:)
a source to share
Access is an old database, why not SQL Express 2005 (witch free)? you will get more security information and inside your application you are using the / pwd user on a connection that no one will know about or be able to see ... if they try to open SQL they will only see the database name and nothing else (not forget to use SQL Authentication and not Windows Authentication)
if you are using .NET, in your installer, you can only install the app install after installing SQL 2005 Express or using another language using InstallShield, FinalBuilder, etc. to do the same ...
:)
you go "fighting" for me when I understand that ... Access started having a bad response time with more than 30k rows in one table (quote from Microsoft) and if you are going to create a layer to encrypt / decrypt the data ... your application will just go from slow to not work at all ... would that be a good idea?
a source to share
I all use Jet wherever appropriate, but when you start worrying about password protecting data outside of what you get with NTFS and Jet ULS security, you are in a territory where you need to use a different data store.
But let me say this:
Security is not a technological issue - it is a human issue. No amount of protection will protect you from a user with administrator permissions who wish you health. You should always trust people enough to give them permission to view and edit your data. Too often, the focus is on how to keep unauthorized users from your data, rather than from developing your application, to protect your data from damage that can be done by authorized users. The former is fairly straightforward, while the latter requires special attention not only to your security settings, but also to how you develop your application.
And at the end of the day, you have to trust people to respond responsibly, and nothing Jet or SQL Server can do to help you.
a source to share
How about updating the MDB format to ACCDB format (Access2007)?
Getting Started with Access 2007 Security
"The encryption tool in Office Access 2007 consolidates and enhances two old tools — passwords and database encryption. When you use a database password to encrypt a database, you make all the data unreadable by other tools, and you force users to enter a password to use the database. The encryption used in Access 2007 uses a stronger encryption algorithm than was used in earlier versions of Access ... "
a source to share
I don't understand if I only read your post if you are trying to protect data, or if you are trying to protect something else, such as only VBA code. You say you have an mdb file, but are you running Access 2003, 2007, or another version? Are you planning to deploy an Access solution on an Intranet website? (For my comments below, I'm going to assume you are.)
I agree with other posters that if you have the opportunity to consider other solutions before deploying an access-based solution, you should. However, if you cannot avoid the Access-base solution, I would like to share the following suggestions and / or comments.
-
If you are working with Access 2003, you may need user and group level security (setting and configuring user / group level security not available in Access 2007 databases (accdb), however Access 2007 recognizes user / Group permissions from mdb files. With level security user / group you can restrict access to your database based on certain users and workgroups For more information - [ http://office.microsoft.com/en-us/access/HP051882261033.aspx] [1 ]
-
Consider partitioning the database (keep your data separate from application objects such as forms, reports) and / or create different versions that restrict the available objects.
-
Keep a master for design and replica for production. This is consistent with the previous comment, where the idea is that not everything is on the table to take. You might want to check out the Access Extensions Extensions (if not already installed) available for 2003 and 2007 (free to download and install from Microsoft).
-
Use policies where possible that discourage and / or restrict employee or employee access (again, I'm assuming you're deploying on a corporate intranet)
-
Encode your database. This will make the property information for your tables and the VBA code harder to extract as the database will be condensed and any project-level information will be deleted or more difficult to access.
-
Finally, if you have the time, resources, and / or a nearby library / bookstore with a copy available, I recommend you check out Alison Balter, mastering Microsoft Office Access 2003 , Check out the "Developing Multiuser and Enterprise Applications" section, which contains a section on security ... Updated for ACCESS 2007: Alison Balter Mastering Microsoft® Office Access 2007
Whichever method you use can be hacked by someone in the know.
It really depends on how valuable the data is: if it is really valuable, I would use a different model, for example, putting the database behind a server on the internet. Then you can limit the number of requests as well as the filter for misuse.
If the leak can be traced or limited, you better protect the data with a license agreement. At the very least, you may have a way to recover your losses. Note that OED recently removed copy protection.
Also think about the future: some network administrators may need legal access to data in 10 years, and using a simple password will show that the data should be protected but still allow circumvention.
a source to share
For a desktop application, I suggest you go the Sql Server Compact Edtition (SQLCE) route . Or, if you have a little money, VistaDB (unlike SQLCE, it supports stored procedures, views, and triggers). You will get better security, better performance, less maintenance and corruption issues, and easier deployment.
a source to share