VBA code to detect if a password has been changed

[isladogs]

As the forum has apparently gone into hibernation recently, I've got two questions that I will post and hopefully wake things up again...

As part of my work on making Access apps as secure as possible, I already have code to detect the state of various properties and where these have been changed, the application quits automatically. For example I check:
a) whether the shift bypass has been re-enabled
b) whether the ACCDE/ACCDB encryption password has been removed
Both of those work perfectly.

However, I would also like to run code to check whether the password has been altered externally.
Does anyone have such code or can suggest how it could be done.
Thanks in advance

[NeoPa]

No idea on that one I'm afraid :-(

[Rabbit]

That depends on what you mean by "changing the password externally". If someone changed the encryption password, you wouldn't be able to open the database anyways?

[isladogs]

Obviously so, but that's not the purpose.
As part of an example database app employing multiple security features, my Encrypted Split No Strings app, I'm hoping to cover all bases of someone tampering with the original files whilst trying to hack the app. Does that make sense?

[Rabbit]

So you are referring to custom encryption and not the full file encryption included in Access? The point still holds that it they change the password, you won't be able to decrypt your data.

But if you're looking to detect whether the data was changed without the attacker knowing the password, then the typical approach for that is to calculate and store a message authentication code.

[isladogs]

Hi Rabbit
I'm talking about full file encryption of both FE and BE though the BE data is further encrypted (see below)
The purpose will probably make more sense if you can spare a few minutes to read the article.

With the current version, I provide the ACCDE FE password but otherwise it is very highly locked down.
Earlier versions of the app have been used (with my permission) in Access security presentations in 2019 & 2020.
Since then, it has been further enhanced.

The ACCDB BE password isn't supplied or needed for this to work as there are no linked tables.
The FE forms use disconnected ADO recordsets as does the report (with a bit of trickery).

The BE password is stored in the FE code but is scrambled using a different function
The data is further encrypted using the RC4 function whose cipher is not supplied. That is also encoded within the FE code
Nevertheless, the app is designed to be fully functional and users are allowed to edit data and add new records. The data is also searchable.

Another version is planned to which I intend to add a few more tweaks.
Detecting a changed file encryption password is one of the few things I haven't yet worked out

Please can you explain exactly what you mean by 'calculate and store a message authentication code'.
Thanks

[Rabbit]

There must be some sort of miscommunicatio n here. If I'm understanding correctly, you want to run code when you open the front end or back end to check whether the full file encryption password has been changed by a third party.

But here's the rub, if someone changes the full file encryption password, you won't be able to open the file anyways and the code to check the file can't run.

Which is what I originally said, but you said that wasn't the purpose. So I don't know what the goal is. Walk me through the scenario. Because what I'm thinking is

• A malicious third party changes the password
• You attempt to open the file, but you can't because you don't know what the password was changed to
• File fails to open and no code runs

[Rabbit]

The high level overview is that message authentication codes tell you whether or not data has been changed by a third party. But they're not a simple topic, best to read an article about them.

This would only apply though to my original thinking that you wanted to check the authenticity of the custom encryption you're using. This does not help you in regards to checking the authenticity of the full file encryption as those contents change too often to make the MAC useful to you.

As for rc4, you really should switch to a more secure algorithm and also use an iv.

[isladogs]

Yes there is miscommunicatio n here which I'm sure is my fault.
Its an example app which I have provided as a security challenge. The idea behind it has already been implemented by several other developers and put into production use. I'm in the process of making further refinements.

As previously stated, I already have security code to automatically quit the FE database when run by a third party (hacker) if the password has been removed or the shift bypass has been enabled by the third party from an external app.
Now as an extra step, I would like to run code to automatically quit the database if the third party alters the password externally and then runs it,

In one sense, it doesn't matter as the FE is still encrypted. The purpose is to further restrict what the third party is able to alter and still be able to run the app.
Does that make sense now?

More than happy to read one or more articles about message authentication codes. Before I do a search, do you have any suggested links you can provide.

[Rabbit]

That's clearer, yes. In an encrypted Access database, the encryption metadata is stored in the file starting at byte 676. It has the salts used, verification hashes, and encrypted key value. If you compare that at run time to the original values at creation, that'll tell you if someone changed anything about the encryption.

Here's the wikipedia article about MACs: https://en.wikipedia.org/wiki/Messag...ntication_code

On a side note, I don't know how much extra security all this stuff buys you. Anyone that knows how to reenable the shift bypass also knows that the shift bypass will prevent any of your code from running in the first place.

[isladogs]

Thank you.
I'll look into whether I can make use of the metadata whilst the file is in use.
Will read up about MACs.

I agree totally with your final sentence. There is far more security involved in the app than I have explained so far.
The current version was made available to various skilled developers over a year ago and publicly via my website last Xmas
So far nobody has solved the security challenge and indeed several have told me they were unable to do so despite a lot of effort.

Perhaps you would like to rise to the challenge?
In the meantime, I'm aware of ways to further improve it. No Access database can ever be made 100% secure from a skilled and determined hacker with sufficient motivation to put in the time and effort needed

[Rabbit]

For your originally stated purpose, you won't need a MAC. But it could be useful if you're looking to verify the integrity of the data that you encrypted in the table.

There shouldn't be an issue opening the file in read mode to read those bytes while it's in use. But if there is, you can just temporarily create a copy and read that.

As far as the challenge goes, that depends on what that is. If it's to break into the full file encryption, then that shouldn't be possible as it uses AES, which is currently unbroken. If it's to get into the back end given that you have the front end password, then that depends on how you implemented the connection to the backend. If you have the backend password as a plain string in the code, retrieving that string is trivial. But if that is obfuscated in any way, then that would require decompiling the code. And I don't really want to wade through machine code.

[Rabbit]

Ok, well, I didn't have to go to the extreme of decompiling the code, just had to inspect the process memory. The backend is removed and the RC4 is removed

[isladogs]

Hi Rabbit
My existing code to check whether the password has been removed works by creating a copy of the database and checking whether that can be opened without a password. So an error indicates its encrypted with a password.
Perhaps I can adapt that to read the relevant bytes. Not looked into it as yet.

Have you read the article about the challenge? If so, you will know the there are no linked tables. Instead it uses disconnected ADO recordsets. The BE password is stored in the code but it is obfuscated. I know how to view the file metadata for such information but I wasn't expecting you to do so

However, there are two vulnerabilities that I've discovered since uploading the challenge. These will be dealt with in the next version.
However. I would be very grateful if you are willing to spend any time looking at it for security weaknesses that you may discover.
If you do so, please can you PM me to discuss rather than post the details in a forum thread

Cheers

[isladogs]

Posts crossed.
I believe I know how you did that. Would you mind removing that info from public view however.
I will PM you