UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Encrytion Standard Used By Default Access 2016 Accdb File, Access 2016    
 
   
Louverril
post Dec 4 2018, 01:19 PM
Post#1



Posts: 504
Joined: 29-April 08



Hi,

This document https://docs.microsoft.com/en-us/deployoffi...ption-in-office 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!

--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
DanielPineault
post Dec 4 2018, 02:44 PM
Post#2


UtterAccess VIP
Posts: 6,721
Joined: 30-June 11



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, ...



--------------------
Daniel Pineault (2010-2019 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
DanielPineault
post Dec 4 2018, 02:45 PM
Post#3


UtterAccess VIP
Posts: 6,721
Joined: 30-June 11



Old but this is what is publically available: https://www.everythingaccess.com/tutorials....-in-Access-2007

--------------------
Daniel Pineault (2010-2019 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
Louverril
post Dec 5 2018, 10:04 AM
Post#4



Posts: 504
Joined: 29-April 08



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





--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
Louverril
post Dec 5 2018, 10:19 AM
Post#5



Posts: 504
Joined: 29-April 08



Hi Daniel,


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

<encryption xmlns="http://schemas.microsoft.com/office/2006/encryption"
xmlns:p="http://schemas.microsoft.com/office/2006/keyEncryptor/password"
xmlns:c="http://schemas.microsoft.com/office/2006/keyEncryptor/certificate">
<keyData saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES"
cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="woPWTMvC0deNZE0F7pnZcw=="/>
<keyEncryptors><keyEncryptor uri="http://schemas.microsoft.com/office/2006/keyEncryptor/password">
<p:encryptedKey spinCount="100000" saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES"
cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="ypqcnKwguMbjTRIVz20vXQ=
=" encryptedVerifierHashInput="Dq1GpNooX36MXjHzke4iBw==" encryptedVerifierHashValue=
"chCznSUI54Ay3QST7H4RVbuaqJ1DtGy15pkAPo0E8J2+TXyv4jsdPzKmt1WnRc6yyb57bttzqY0
6UU2iouAaXQ=
=" encryptedKeyValue="4eNhWO3m17PS+j+SL13aC6KCYoHLHsZ4RALa0NpQkz4="/></keyEncryptor>
</keyEncryptors></encryption>


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.



--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
DanielPineault
post Dec 5 2018, 12:13 PM
Post#6


UtterAccess VIP
Posts: 6,721
Joined: 30-June 11



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.


--------------------
Daniel Pineault (2010-2019 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
Louverril
post Dec 5 2018, 12:51 PM
Post#7



Posts: 504
Joined: 29-April 08



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

--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
isladogs
post Dec 5 2018, 01:10 PM
Post#8


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


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

<encryption xmlns="http://schemas.microsoft.com/office/2006/encryption" xmlns:p="http://schemas.microsoft.com/office/2006/keyEncryptor/password"><keyData saltSize="16" blockSize="16" keyBits="128" hashSize="20" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA1" saltValue="Ry2+EayYULhSNV/mA0Visg=="/><keyEncryptors><keyEncryptor uri="http://schemas.microsoft.com/office/2006/keyEncryptor/password"><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?
This post has been edited by isladogs: Dec 5 2018, 01:13 PM

--------------------
Go to the top of the page
 
Louverril
post Dec 6 2018, 06:25 AM
Post#9



Posts: 504
Joined: 29-April 08



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.

--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
isladogs
post Dec 6 2018, 06:37 AM
Post#10


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


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

--------------------
Go to the top of the page
 
FrankRuperto
post Dec 6 2018, 11:00 AM
Post#11



Posts: 198
Joined: 21-September 14
From: Tampa Bay, Florida, USA


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

--------------------
Currently supporting many pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
isladogs
post Dec 6 2018, 11:51 AM
Post#12


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


QUOTE
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.

--------------------
Go to the top of the page
 
DanielPineault
post Dec 6 2018, 12:00 PM
Post#13


UtterAccess VIP
Posts: 6,721
Joined: 30-June 11



QUOTE
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?



--------------------
Daniel Pineault (2010-2019 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
isladogs
post Dec 6 2018, 12:16 PM
Post#14


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


Daniel,
You will note I wrote
QUOTE
Nor is the full password stored in the ACCDB/ACCDE file - not even in encrypted form


This quote is from https://www.everythingaccess.com/tutorials....-under-the-hood

QUOTE
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

QUOTE
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.


NOTE:
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.


--------------------
Go to the top of the page
 
FrankRuperto
post Dec 6 2018, 12:17 PM
Post#15



Posts: 198
Joined: 21-September 14
From: Tampa Bay, Florida, USA


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

--------------------
Currently supporting many pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix and Oracle DB's.
Go to the top of the page
 
DanielPineault
post Dec 6 2018, 12:33 PM
Post#16


UtterAccess VIP
Posts: 6,721
Joined: 30-June 11



Thank you for the precision.

--------------------
Daniel Pineault (2010-2019 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
isladogs
post Dec 6 2018, 01:05 PM
Post#17


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


Frank
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 http://www.mendipdatasystems.co.UK/compare...rity/4594444323

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.

--------------------
Go to the top of the page
 
Louverril
post Dec 6 2018, 02:00 PM
Post#18



Posts: 504
Joined: 29-April 08



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"):


Attached File  msyssnip.JPG ( 13.65K )Number of downloads: 1




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

All Access 2016
This post has been edited by Louverril: Dec 6 2018, 02:12 PM
Attached File(s)
Attached File  msyssnip.JPG ( 13.65K )Number of downloads: 0
 

--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
isladogs
post Dec 6 2018, 02:23 PM
Post#19


UtterAccess VIP
Posts: 1,462
Joined: 4-June 18
From: Somerset, UK


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.
This post has been edited by isladogs: Dec 6 2018, 02:24 PM

--------------------
Go to the top of the page
 
Louverril
post Dec 7 2018, 10:37 AM
Post#20



Posts: 504
Joined: 29-April 08



IslaDogs,

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.... :-(








--------------------
Cheers!

Allyson
UK North Yorkshire / North East
Go to the top of the page
 
2 Pages V  1 2 >


Custom Search


RSSSearch   Top   Lo-Fi    23rd July 2019 - 08:18 AM