Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Access Security _ Encrytion Standard Used By Default Access 2016 Accdb File

Posted by: Louverril Dec 4 2018, 01:19 PM


This document from Microsoft says "Although there are Office 2016 settings to change how encryption is performed, when you encrypt Open XML Format files (.docx, .xslx, .pptx, and so on) the default values AES (Advanced Encryption Standard), 256-bit key length, SHA1, and CBC (cipher block chaining) provide strong encryption and should be fine for most organizations. AES encryption is the strongest industry-standard algorithm that is available and was selected by the National Security Agency (NSA) to be used as the standard for the United States Government. AES encryption is supported on Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012."

Near the top of the document is does give the impression that this includes Access "Office 2016 contains settings that let you control the way that data is encrypted when you use Access 2016, Excel 2016, OneNote 2016, PowerPoint 2016, Project 2016, and Word 2016."

Can I deduce from this that the default the default encryption for Access 2016 accdb files is AES (Advanced Encryption Standard), 256-bit key length, SHA1, and CBC (cipher block chaining)?

If not does anyone no what it is - I have done a lot of searching but can't find anything more definite that the above for Access 2016.

Many thanks!

Posted by: DanielPineault Dec 4 2018, 02:44 PM

I'll see if I can dig up a link I had found many moons ago that explained how the encryption could be changed, but it wasn't easy.

That said, if you are looking into encryption of an Access database, you shouldn't be using an Access database! If you data is confidential and gives you concern to be looking into this you really should be using another RDMS for the backend such as SQL Server, Azure, Oracle, ...

Posted by: DanielPineault Dec 4 2018, 02:45 PM

Old but this is what is publically available:

Posted by: Louverril Dec 5 2018, 10:04 AM

Thank you very much Daniel - pity there is nothing more up to date!

Posted by: Louverril Dec 5 2018, 10:19 AM

Hi Daniel,

I opened an encrypted database in notepad (idea from the link you posted) and got this:

<encryption xmlns=""
<keyData saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES"
cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="woPWTMvC0deNZE0F7pnZcw=="/>
<keyEncryptors><keyEncryptor uri="">
<p:encryptedKey spinCount="100000" saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES"
cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="ypqcnKwguMbjTRIVz20vXQ=
=" encryptedVerifierHashInput="Dq1GpNooX36MXjHzke4iBw==" encryptedVerifierHashValue=
=" encryptedKeyValue="4eNhWO3m17PS+j+SL13aC6KCYoHLHsZ4RALa0NpQkz4="/></keyEncryptor>

cipherAlgorithm="AES" sounds good? And hashAlgorithm="SHA512"? And cipherChaining="ChainingModeCBC" ?

Get what you say about using SQL back end but was curious.

Many thanks again.

Posted by: DanielPineault Dec 5 2018, 12:13 PM

Interesting, and somewhat good news.

The real issue with Access security is that the file can easily be copied and cracked elsewhere with easily available tools, unlike other RDMS.

Posted by: Louverril Dec 5 2018, 12:51 PM

Yes - I try to write in code that ties them to be used in a certain location. including if they have a SQLServer backend.

Posted by: isladogs Dec 5 2018, 01:10 PM

I'm surprised you're getting 256-bit encryption.
This is my equivalent with access 2010 as my primary Access version:

<encryption xmlns="" xmlns:p=""><keyData saltSize="16" blockSize="16" keyBits="128" hashSize="20" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA1" saltValue="Ry2+EayYULhSNV/mA0Visg=="/><keyEncryptors><keyEncryptor uri=""><p:encryptedKey spinCount="100000" saltSize="16" blockSize="16" keyBits="128" hashSize="20" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA1" saltValue="Z5YDs1YW4Nb46PvJ6V2Cxg==" encryptedVerifierHashInput="YYJtyN2xC6FnEp5TX+2EmA==" encryptedVerifierHashValue="exExnGV9fRXvL092ogEcFcJ2kAGJw7GRvTxc385EX0I=" encryptedKeyValue="vOOWREQQhT/85kKDo11FUA=="/></keyEncryptor></keyEncryptors></encryption>

I am using 'Default encryption (higher security)
IIRC the legacy encryption alternative is 32-bit or 40-bit
Which version of Access are you using and have you changed any settings to get 256 bit SHA512 encryption?

Posted by: Louverril Dec 6 2018, 06:25 AM

Hi Isladogs,

It must be because I am using version 2016 (nb: office365 - so it will be bang up to date). And I am using the default encryption "Default encryption (higher security)" - have not made any changes at all - or attempted to do so.

Just checked it was the 'Default encryption (higher security), encrypted the db and then open it with notepad.

Posted by: isladogs Dec 6 2018, 06:37 AM

OK thanks - I'll try on another PC with Office 365 & report back if mine is still different.

However, in my opinion 128 bit encryption is more than enough for data that is appropriate for storing in Access.
Otherwise use SQL Server as previously mentioned

Posted by: FrankRuperto Dec 6 2018, 11:00 AM

What good is AES encryption if the password is stored as plain text in the Windows registry?

Posted by: isladogs Dec 6 2018, 11:51 AM

What good is AES encryption if the password is stored as plain text in the Windows registry?

I'm sure you've written this before, possibly in my security challenge thread, and that I written this answer before.
It isn't!
That is unless you've chosen to add it to the registry yourself.

Nor is the full password stored in the ACCDB/ACCDE file - not even in encrypted form

However if you have evidence to tell me I'm wrong, do let me know.

Posted by: DanielPineault Dec 6 2018, 12:00 PM

Nor is the full password stored in the ACCDB/ACCDE file - not even in encrypted form

I find that very hard to believe. Since the file works if you move it to another PC, then password (in some shape or form) would need to be stored within the file itself, no?

Posted by: isladogs Dec 6 2018, 12:16 PM

You will note I wrote

Nor is the full password stored in the ACCDB/ACCDE file - not even in encrypted form

This quote is from

The password is no longer stored as obfuscated plain text in the file header. Instead, a hash is used to check that the user has entered the valid password. The hash is generated from a combination of RC4 and SHA-1 algorithms.
Once the password is validated against the hash value, the password is then used to decrypt the RC4 encryption throughout the file.

Here is some further explanation by AWF member TheDocMan

The hash-checking algorithm is based on the same technology that gives you digital signatures. In essence, a signature is a polynomial (in binary, of course) based on some obscure formula that gives you a long string of bits by multiplying two numbers together in some orderly pattern. When you complete the multiplication you have a hash (which in math is sometimes called a "characteristic") that depends on the contents of the thing you were trying to sign. It doesn't matter whether the thing being protected is short or long. When you attach the hash value as part of the item you have signed the item in a way that is very difficult to spoof. If you send the hash in a separate signature file, your recipient can confirm your identity.

In general, if you have a 128 bit hash, that hash sequence has 2^128 possible values, which is roughly 512 * ( 10^36 ). So the odds of accidentally generating the same hash value from two different inputs SHOULD be 1 divided by that number, which is pretty small - something like 0.2 * ( 10^ -38 ).

There are ways to determine how big a file has to get before that probability gets big enough to even worry about. But the point is, if you store the HASH of something and then later input that something again, you can't compare the something - but you CAN compute the HASH of something and compare it to the stored hash. If the hashes match, the inputs probably also matched.

Now, the only other two things that might be confusing is that RC4 and SHA-1 are two popular hash-generating algorithms. Each is based on a different polynomial. So if you enter a password and BOTH of the resulting two hashes match the stored hashes, you are fairly sure that the right thing was entered. After that, the database decryption key can be generated from the password.

Why is this any better than simply obscuring the password? (You might ask?) Because the hash computation is one-way. It is irreversible. The fact that the hash is of a fixed length means that if an overflow occurs out of the high-order bit of the hash slot, bits get lost and without those lost bits, you have a very large number of possible solutions to the polynomial. Not QUITE infinite since the inputs had to be finite - but it is a REALLY BIG number of possible solutions.

The password used to be stored with weak XOR encoding within the file in the old MDB/MDE file format and was very easy to crack.
That changed with the ACCDB format
Now AFAIK only a brute force attack will work testing every possible combination of characters until one works .... which could take days
I tried doing so on one of my own apps once - I left the code running overnight and it was nowhere close to reaching my test password.
Given a sufficiently strong password it is highly unlikely it will be cracked unless the data is so valuable it is worth the time needed - but if so, it shouldn't be in Access anyway.

Posted by: FrankRuperto Dec 6 2018, 12:17 PM

I stand corrected, nevertheless several tools such as refixer are easily available for bypassing mdb and accdb passwords.

Posted by: DanielPineault Dec 6 2018, 12:33 PM

Thank you for the precision.

Posted by: isladogs Dec 6 2018, 01:05 PM

As previously stated, MDB/MDE passwords are easy to hack. Many free and commercial tools are available that do this.

ACCDB passwords are much harder to crack and brute force is normally required unless you have a good idea what the password is already.
When I was testing security in MDB/ACCDB files i also bought a commercial tool to do this.
Like my own code, it worked but was incredibly slow unless the password was very short.

It wasn't the refixer tool you mentioned which I'd never heard of.
However I've just found that online and its the same app as I bought under a different name.

For clarity, I'm not referring to the VBA project password which is ridiculously easy to bypass

I've written some lengthy articles on Access security on my website. For example

Access is by no means a highly secure application partly because it is file based. However ACCDB encryption is one of its better security features.

Posted by: Louverril Dec 6 2018, 02:00 PM

Hi All,

Please see attached snip

If you use a short Password you can certainly see the password. This query looks at the msysdata table in a (non encrypted) remote front end (not the same front end as the query is in) linked through to an encrypted back end (encrypted "Default encryption (higher security"):

I ran out of time to see what happens if you use a long password. I will get back tomorrow.

All Access 2016


Posted by: isladogs Dec 6 2018, 02:23 PM

Yes that is definitely the case - for both linked Access & linked SQL tables.
The length of the password is absolutely irrelevant in this context.
That is one of many reasons why end users should never be able to view any tables - especially not system tables

If you open an unencrypted file MDB/MDE/ACCDB/ACCDE in Notepad, you can also read lots of information including connection strings, table names, field names , table contents etc. The linked article on my website from my last post gives plenty more details about all of this and more.

Therefore if you use an Access BE containing data that needs to be reasonably secure, this should always be encrypted.
To repeat a SQL Server BE is much more secure than Access can ever be.

The FE should be distributed as an ACCDE file and security included to disable the navigation pane, Access special keys, Access options etc etc.
I normally remove the ribbon as well and sometimes hide the taskbar whilst an app is running.
But you only need to leave one area of weakness for knowledgeable hackers to be able to exploit it.

Posted by: Louverril Dec 7 2018, 10:37 AM


I was hoping this comment from you "Nor is the full password stored in the ACCDB/ACCDE file - not even in encrypted form" meant that you could not see all the password if it was long? I must have misunderstood and you meant the linked to ACCDB not the FE msysdata table linking to it. You can certainly see a short one. Still haven't had chance to test a long one yet.

I read something I think it was on Daniel Pineault's website that even if you encrypt the front end that is linked to an encrypted back end, once the front end is opened you can use getobjects() to look at the msysdata. I haven't had time to try this yet.

So I can't see ANY way of hiding the password.... :-(

Posted by: isladogs Dec 7 2018, 01:04 PM

Hi Allyson

I was very careful in my choice of words - perhaps too careful as I didn't mean what you thought.

If you read post 14 including the link provided, you should get a better idea of how Access stores & retrieves the password information.
If you also read post 17 & the linked article on my website you will get further information about the information that can be easily retrieved from unencrypted Access files.

However don't confuse two different things.
If you encrypt an ACCDB/ACCDE file with a password the entire file is encrypted and is almost impossible to read with any external software.
However if you link an Access FE to a BE file (encrypted or not), the connection strings are stored in the hidden system table MSysObjects
For info, if you know how to do it, you can also look at that table from another Access database

No matter how long your BE passwords ( I think 20 characters is the max allowed), these will appear in full in the connection string.
So these will always be visible if you look at the Connect field in MSysObjects.
As that table cannot be edited (at least not directly), you cannot hide or mask passwords in those connection strings.

So if you need to prevent users knowing the BE password(s), you need to lock down your FE file to prevent users being able to view system tables
There are many security measures you can do to make it very difficult for users to 'hack' your applications.
I mentioned some of those in my last reply.
If you are interested, there are a number of on my website.
Even if you don't try & solve them, you can look at what I've done to limit user access.

There is one other solution that can work in certain limited cases.
Do not have BE tables that are permanently linked to your FE.
Instead use code containing SQL statements to set form & report record sources in their Load or Open events
Do NOT save it in the form/report property sheet. Destroy that recordsource when the object is closed
Use an ACCDE file so nobody can read the code used
The result is a fully functional split database with no linked tables so no connection strings visible in MSysObjects

To help explain this idea, see the attached simple demo. The zip file contains an ACCDB FE, encrypted BE (password=isladogs) and a Word doc explaining how to use the demo

However, do remember that Access is not intended for mission critical data security.
If there are serious data privacy issues, instead use e.g. SQL Server to store your BE data ( 476.62K ): 9

Posted by: Louverril Feb 1 2019, 10:59 AM

I was wrong!

If the password is long - I used 20 characters - the max - you cannot get it from msysobjects - I worked it through here (there is a DB example attached) - see my second post.

So this is pretty secure????? Combined with the below "cipherAlgorithm="AES" sounds good? And hashAlgorithm="SHA512"? And cipherChaining="ChainingModeCBC" ?
" enhanced security in Access 2016.

So is there any way of getting to this long password in the DBTestEncENCRYPTENCRYPT123420.accbd (password is ENCRYPTENCRYPT123420 ) - see link above.

Posted by: isladogs Feb 1 2019, 11:52 AM

I've responded in your other thread:

There is a big flaw which means the linked table is unuseable with a 20 character password