I thought I’d briefly cover the subject of Access database encryption and password protection.

Historically, when we talk about the mdb file format, password protection was pretty much useless and could easily be cracked with free and widely available online tools. With the newer accdb file format things changed and cracking them seems harder. One word of caution here is that I’ve just recently been made aware that a company is developing, or has developed, an Access password cracker that they say can do so nearly instantaneously.

That said, it is my personal opinion that every database should be password protected.  I take things a step further and, not only password protect them, but also place them on an encrypted drive.

Password Protecting Your Database Through the GUI

Now, the process of password protecting (or Encrypting is Microsoft’s term for it, because it does more that merely adding a password to the file itself) an Access database is very simple:

File -> Info -> Encrypt with Password

and then you are presented with the following dialog

in which you simply enter your desired password, confirm it by entering it a second time, then press OK and you are done!

Password Protecting Your Database Using VBA

Nothing could be easier than applying a password to your database through code and it can be accomplished with a single line of code!

CurrentDb.NewPassword "OldPassword", "NewPassword"

When encrypting a new database which has no password yet, the first argument should be “”.

In the case that you wish to remove the password from , decrypt,  a database, then the 2nd argument should be “”.

You can review the official documentation on the NewPassword Method.

When To Secure Your Database

The short answer is after it has been split.

The longer answer is if you secure a database and then split it, surprisingly enough, the resulting back-end is not secured!  So split it, encrypt the back-end , then link the tables.

Should the Front-End be Secured?

This is a great question and I don’t have a single, one size fits all answer here.  You ultimately have to make that decision for yourself.

The primary issue with Access is the fact that it is a file, and can be copied and taken else for use, hence the CRITICAL importance of encrypting the back-end file.

Whether or not encrypting the front-end is a matter of opinion.

I typically believe it should be.  My reasoning is as follows:

• If someone can copy the back-end, then they’re probably in a position to copy the front-end.  Then a quick relink and they have access to the data that you tried the protect.
• If it isn’t secured, then anyone can access it and the back-end password is store within the linked table connection property and can very easily be extracted as I explained in my post Why MS Access isn’t a Secure Database & Why MS Access isn’t a Secure Database – Part 2 therefore they can extract the back-end password through the front-end.

Ultimately, I think more security is normally a good precaution.

Password Length and Limitations

One important thing to note is that Microsoft Access’ password can be a maximum of 20 characters in length.  I’ve seen documentation stating 14, I’ve seen threads stating much higher, but when I tested, neither the GUI, nor VBA would accept a password length beyond 20 characters.

That said, if you you use a 20 character password on a single file Access database everything is fine, but if you do so on a split database you will receive the following error

So, to avoid any issue, never use a password any longer than 19 characters in length!

Final Thoughts on Access Database Security

Security is not a single element, such as just encrypting a database.  It is, or at least should be, a multi-faceted practice.

Encrypting your database should be one of a number of security measure you put in place, things like, but not limited to:

• Hidden folder to house the back-end
• Lock down the permissions on all the folders so only specific personnel can access them in the first place
• Code the database to close if not run in the proper directory
• Code the database to close if the username isn’t in the approved user listing
• Deploy the front-end as an accde
• etc.

As with any password, make sure you use the longest one possible, so 19 characters in length, utilizing characters (both upper and lowercase), numbers, symbols to.  None of these ‘123’, ‘abc’, ‘password’ passwords!