Looking to take your VBA skills further?...

Discover twinBASIC — a powerful new development platform that expands on VBA and VB6 with advanced features, modern tools, and enhanced compatibility. Perfect for those ready to elevate their projects or transition from VBA, twinBASIC lets you build on what you already know and take your applications to the next level!

Try out twinBASIC Community Edition - it's free!

Changing the encryption type in Access 2007

1263 votes:

22,28 views 21 comments

by Wayne Phillips, 28 May 2008 (for Access )

This article is split into two parts:

Part 1 – Upgrading the default encryption to RC4-128

Part 2 – Breaking through the boundaries - Upgrading the encryption to AES-256

As most Access developers know, the encryption system used in Microsoft Access prior to v2007 was as useful as chocolate teapot. Seriously. I won't be going over the details again here as it’s been proven many times before that all the option does is slow down your database activity without providing any real protection.

Access 2007 is a different ball game. Access 2007 solves this by using the Crypto API coupled with using the database password as the encryption key, just like all the other Office applications. The Crypto API itself gives developers and users access to a number of different ‘Cryptographic Service Providers’. These providers each offer various encryption algorithms and key length options, depending on what the provider was designed for. Those kind people at Microsoft have provided us with many different providers, giving us access to a wide variety algorithms for free (since they are built in to the operating system).

At this point I should mention that the new encryption system is only provided in the new .ACCDB file format. Older .MDB formats are not affected.

A question on the subject of the new Access 2007 encryption got forwarded to me the other day from Garry Robinson over at vb123.com (originally from a guy named Mark Jacobs):

Hi Garry,

 I hope you can help me with an issue concerning Access 2007 encryption 
 as I have not found anything on the web that has addressed it. 

 I'm getting pushback from my Security group because they do not think 
 Access 2007 can use the Microsoft Enhanced RSA and AES Cryptographic Provider. 
 All we see when we load an encrypted Access database in notepad is 
 M i c r o s o f t B a s e C r y p t o g r a p h i c P r o v i d e r v 1 . 0. 
 
 Microsoft quoted otherwise in their article (see link) and that is where the 
 confusion lies:
 
 Office 2007 Security Guide 

 Maybe there is some sort of XP [group] setting I don't know about. 
 Any ideas would be appreciated as I am at my wit's end. 

 Thank you, 
 
 Mark Jacobs

Good question, Mark. Indeed, the mentioned article is definitely wrong.

The default encryption provider for Microsoft Access is the 'Microsoft Base Cryptographic Provider v1.0', with RC4 encryption (using a 40-bit key) and the SHA-1 algorithm for password/key hashing.

Why RC4?

Although Access 2007 now uses the Crypto API, we are limited in what encryption algorithms we can use due to the way in which Access reads and writes to the database file. To understand why, let’s discuss the technical details.

The Access Database Engine stores data in pages (or ‘chunks’) of 4096 bytes in length. Understandably, encryption also occurs at page-level within the file (each page being encrypted with a different encryption key).

If Access was to read and write to the file in full 4096 byte pages, then we could theoretically use any block cipher encryption such as the much stronger AES algorithm. Unfortunately this is not the case, by default. When Record-level locking is switched on, Access writes to each record individually. In other words, when you change values in a record within a table, the whole 4096 byte page is not re-written to disk – only the single record data is written out.

Normal block ciphers will not work in this scenario since data is encrypted in blocks, not byte by byte. Encryption that is done by the byte (or even per bit) requires a special type of algorithm – called a stream cipher. (There is a way around this limitation which will be discussed later in part 2)

The standard Microsoft Cryptographic Service Providers (CSPs) only provide support for one stream cipher… RC4. So unless you have third party CSPs that offer other stream ciphers, we’re stuck with RC4.

So we're stuck with RC4. What's the protection like?

By modern standards it does fall short, although in reality it's not too shabby. It's implemented very well into Access to prevent from known RC4 crypto attacks that prey on the weaknesses of the algorithm. For example, every encrypted 'page' has a unique key which is derived from a password hash (which includes random base data) combined with a nonce.

The default encryption uses only a 40-bit key, which does let it down a little, but fortunately this can be bumped up to 128-bit (read on).

The database password is no longer stored in the file, so only brute-force password recovery is possible.

Recommendations

Switch to RC4-128 bit key length (read on for more details)
Use strong passwords to prevent brute-force attack

Stronger than the 'Microsoft Base Cryptographic Provider'

The default Cryptographic Service Provider is 'Microsoft Base Cryptographic Provider' and this provider allows RC4 with up to 56-bit key length. I suggest we need to increase this to 128-bit, but you will need to change the Cryptographic Service Provider setting in the registry in order to do this.

At this point I’m going to introduce you to a freeware utility that will allow you to change the default encryption provider very easily without having to worry about the technical details…

The Encryption Manager for Microsoft Access 2007

The Encryption Manager lets you change the encryption type on any already encrypted .ACCDB database, and also gives you the option to change the registry setting that overrides the default encryption provider in Microsoft Access.

Download here: www.everythingaccess.com/downloads/EncryptionManagerv1.zip

When you open the application you’re given 3 options;

Option 1 is for viewing and changing the encryption used on a particular database
Option 2 is for viewing the details on all of the Cryptographic Service providers installed on your machine.
Option 3 is for changing the default CSP and algorithms used by Microsoft Access 2007.

You want the third option. My recommendation is to set the default to 'Microsoft Enhanced Cryptographic Provider v1.0' with RC4-128 as it is available on almost all modern systems.

Once the setting has been saved, each time you use the 'Encrypt with Password' option in Access 2007 your file will be saved with the new RC4-128 encryption. This can be checked by using the Encryption Manager (option 1) to open the file and it will show you exactly what encryption settings have been used on your file.

If you’d prefer to modify the registry yourself, read the note further below.

Don't forget to have a look at the follow up article (Page 2) here:
Part 2 – Breaking through the boundaries - Upgrading the encryption to AES-256

Modifying the registry manually

Warning: Backup your registry before making changes

Before proceeding please read the restrictions. (The free Encryption Manager application does all this for you)

Restrictions on changing the default Cryptographic Service Provider

1. The Cryptographic Service Provider you choose must support the RC4 algorithm (CALG_RC4)
2. The Cryptographic Service Provider you choose must support the SHA-1 algorithm (CALG_SHA)

For details on the Microsoft installed CSPs capabilities, please see this article: CryptoAPI Cryptographic Service Providers or use the Encryption Manager (option 2) which shows all the details you need for the CSPs installed on your machine.

My recommendation is to use the 'Microsoft Enhanced Cryptographic Provider v1.0' with RC4-128. I will now show you exactly how to achieve this.

Changing the default Cryptographic Service Provider

To change the Cryptographic Service Provider, you need to alter a registry setting. The registry key is as follows;

1. Create registry key (if it doesn't exist):
HKEY_CURRENT_USER/Software/Microsoft/Office/12.0/Common/Security
	
2. Create Multi-String Value (if doesn't exist):
HKEY_CURRENT_USER/Software/Microsoft/Office/12.0/Common/Security/DefaultEncryption
	
The format for the multi-value string is:
Value 1.  Encryption provider name
Value 2.  Encryption Algorithm
Value 3.  Encryption Key Length
	
More details here: [http://office.microsoft.com/en-gb/help/HA011403111033.aspx] Important Aspects of Password and Encryption Protection (see heading 'Updating Encryption', although this article applies to Office 2003 but does not affect Access 2003 encryption) DOCUMENT NO LONGER AVAILABLE
3. For the purpose of this example, enter (on 3 seperate lines):
Microsoft Enhanced Cryptographic Provider v1.0
RC4
128

Rate this article: Your rating: Poor Your rating: Not so good Your rating: Average Your rating: Good Your rating: Excellent

Give me more tutorials!

Have your say - comment on this article.

What did you think of 'Changing the encryption type in Access 2007'?

1.	*Tony Jollans says...*	04 Jun 2008
	Information on this subject seems sparse. I am trying to make this work in Word but can't get very far with it. There is a Microsoft KB ((http://support.microsoft.com/kb/946621).) that says the registry Value should be called "DefaultEncryption12" instead of "DefaultEncryption". When I use "DefaultEncryption" (in compatibity mode), Word 2007 crashes. When I use "DefaultEncryption12" it doesn't crash but it seems to ignore the registry value and insists on using Word 97/2000 compatible 40 bit encryption. I do realise that this may be 'just' a problem with Word but I do have a couple of questions: 1. Does it work in Access - even using "DefaultEncryption"? 2. Is there another setting somewhere that affects this?

2.	*Wayne Phillips says...*	05 Jun 2008
	@Tony... Well, from an Access point of view it is definitely DefaultEncryption. DefaultEncryption12 does not work. DefaultEncryption does. Use the Encryption Manager for Access 2007 (provided with this article) to change the registry key, to be safe (the registry key is common to Word 2007 when saving in Word 2003 format) I've just tested on Word 2007, saving to Word 2003 format, with the same DefaultEncryption registry entry (provided by the Encryption Manager) and it worked just fine. I then opened the file in a hex editor and could find the Cryptographic Service Provider name I chose in Unicode somewhere in the file, so it worked. However, I did experience a crash once upon changing the password (I couldn't reproduce it though). It seems a little flakey in Word 2007 SP1, to be honest.

3.	*Tony Jollans says...*	05 Jun 2008
	Thank you, Wayne, I think the "DefaultEncryption12" may be a red herring - I'll see what I can find out about it. I had been working with documents created in Word 2003 and hadn't thought to try to create a 2003-format document in 2007. I now see that that works with "DefaultEncryption" as you say so my problem is related to how Word 2007 handles documents created in 2003. I won't take up any more of your Access time :)

4.	*Wayne Phillips says...*	05 Jun 2008
	No problem, Tony. If you find out more about the DefaultEncryption12 setting, let me know.

5.	*genesis says...*	23 Jul 2009
	can we improve the database password encryption of access 2003 also? or encryptionmanager for version 2003!

6.	*Wayne Phillips says...*	23 Jul 2009
	Genesis, Unfortunately, it is not possible to increase the encryption strength in Access 2003.

7.	*genesis says...*	24 Jul 2009
	why not? may I know why?

8.	*Wayne Phillips says...*	24 Jul 2009
	Genesis, it is because Access 2003 (and prior versions) use a fixed implementation of the RC4-32 algorithm (an extremely weak implementation of it, actually). Only starting with Access 2007 did they move to using the Windows Crypto API to implement the encryption - that is why it is now customizable to some extent. Regards, Wayne

9.	*Nadia says...*	28 Feb 2010
	Hi Wayne, Thank you for the article, looks interesting. If I want to use my database encrypted with Encription Manager installed on my computer - do I need it (ER) to be installed on other computers if I want to distribute a database? Regards, Nadia

10.	*Wayne says...*	28 Feb 2010
	Hi Nadia, Thanks for your comments. No, you don't need the Encryption Manager installed on your end-users machines. Please note that the "enhanced" mode offered in the Encryption Manager is no longer supported by us since this requires the EncryptionEnhancer DLL to be installed on your client machines, yet this DLL is no longer available. Regards,

11.	*Wayne says...*	26 May 2010
	Hi John, Indeed - that's the expected behaviour. The registry setting only changes the default cryptographic provider that will be applied to your file by Access. Since you've used Encryption Manager to change the encryption level of your file, you won't need to change the registry. Access will keep the encryption settings you've chosen for your file active unless you decide to remove the encryption and re-apply it (in which case the default registry settings would then apply). HTH Wayne

12.	*Wayne says...*	26 May 2010
	Yep - that's exactly right John. As far as I'm aware, RC4 is still the only stream cipher available, so you're stuck with that, and furthermore I believe the higest available RC4 key length is still 128bit, so in short: yes, RC4-128 would be the best available for Access 2007. Not so long ago I wrote some heavily optimized routines in assembly to brute force decrypt an Access 2007 ACCDB (not cracking the password, but the underlying encryption keys), and the time it took to decrypt (any size file) was around 7 hours using an 4-core (8 inc HT) 3ghz Core i7 CPU. That was using the default RC4-40 used by Access 2007. Now consider that each extra 8 bits of key length added to the encryption algorithm expands the total possible key space to be searched (by a brute force attack) by a factor of 256, and you will quickly realize that even RC4-48 would be sufficient in most circumstances given the current limitations of modern hardware (7 hours x 256 = 1792 processing hours). So, in reality RC4-128 certainly isn't too shabby when compared to the previous options we've had in Access. A brute-force attack on the RC4-128 key space is _way_ out of reach of modern hardware and therefore the weakest point is most certainly the password, and it sound like you've got that covered. Wayne

13.	*Wayne says...*	26 May 2010
	No problem. They should be the same since they're both effectively the same algorithm, just packaged in a different provider. I guess the reason for Microsoft offering both would be that one will be available on older operating systems whilst the newer provider probably offers more options and combinations of encryption/hashing algorithms, (although they're not usable by Access 2007 so that doesn't matter to us).

14.	*Rob says...*	02 Nov 2011
	Hey Wayne, thanks for the info. According to: http://technet.microsoft.com/en-us/library/cc148224.aspx Looks like Access 2007 now uses 128 bit keys by default. "For Office Access 2007 databases (.accdb) and Office Open XML documents in the Windows® XP Professional operating system, the cryptographic service provider (CSP) is Microsoft Enhanced RSA and AES Cryptographic Provider. The cryptographic algorithm is AES-128, and the cryptographic key length is 128-bit." Since Access 2010 provides "legacy" encryption and "Higher security" as its options, does that mean 2010 Provides 128-bit (legacy??) and 256-bit (Higher security??) Thanks again! Rob

15.	*Wayne says...*	02 Nov 2011
	Hi Rob, No, despite their claims, Access 2007 is limited to RC4 (more specifically; stream-ciphers only), as described in this article. Any Microsoft articles that say differently are simply wrong. Access 2010 does support AES (and as you mention, it is indeed the default option which is incompatible with A2007). It only manages this by forcibly turning off record level locking to accommodate non-stream ciphers such as AES. Wayne

16.	*Rob says...*	02 Nov 2011
	Thanks! I did a quick test and my Access 2007 file (encrypted) has "M i c r o s o f t B a s e C r y p t o g r a p h i c P r o v i d e r v 1 . 0 " in it when opened in notepad. Same for 2010 when I use "legacy" encryption. 2010 strong has: a bunch more info, including "AES" and keybits = "128" in it. The reason why I'm looking into this is I'm at the point of transitioning all my 2003 db's with ULS and encoding, into 2007/2010 db's (without ULS). Been an eye-opening experience. By the way, do you post on UtterAccess.com?

17.	*Wayne says...*	02 Nov 2011
	You're welcome. The Access 2007 encryption header is stored in binary form, so in a text editor all you would see is the crypto provider name (though in a hex editor you should be able to pick out the other fields, e.g. the crypto API CALG_RC4 value of &H6801). Access 2010 (non-legacy encryption mode) stores the encryption fields in an XML string, so you can easily pick out the encryption fields. I do occasionally post over on UA, but unfortunately haven't had much free time of late! Wayne

18.	*Mark says...*	17 Mar 2014
	I found this tool very helpful recently. I hope you do keep it available. Can anyone tell me if there will be any compatibility issues if I use the tool to upgrade the encryption on my own computer, but distribute Access runtime applications to other computers? Will those other computers need upgrading also, or will the encryption capabilities be compiled into my application?

19.	*Wayne says...*	18 Mar 2014
	Mark, glad to hear that, and thanks for the feedback. Once you have applied the encryption to the file, the encryption algorithms are fixed for that file (unless you decrypt and re-apply password/encryption). Provided the chosen encryption provider/algorithm are available on the end user machine, there should be no issues at all.

20.	*Mark says...*	18 Mar 2014
	Thanks Wayne. My impression is that the Microsoft Enhanced and Strong encryption algorithms are pretty much universal on Windows but would you agree with this?

21.	*Wayne says...*	18 Mar 2014
	You're welcome, Mark. Not 100% sure actually, as this document suggests some providers are dependant on individual countries export restrictions: http://technet.microsoft.com/en-us/library/cc962093.aspx

Have your say...

iTech Masters | VAT: GB202994606 | Terms | Sitemap | Newsletter

Name
E-mail	(e-mail address will be kept private)
Comments

	Comments require approval before being displayed on this page (allow 24 hours).