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 miscommunication 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 miscommunication 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

[isladogs]

Many thanks for making that change. I've just set the best answer as post #12

[NeoPa]

He he. Only moderators can now see what the codes are :-D

[isladogs]

Yes I realise that but of course you are far too well behaved to do anything with that info...😁 Yeah, right!

Perhaps more importantly, I was confident that I knew how Rabbit had got that info and he confirmed that was the case via PM.
The method is relatively obscure but both simple and depressingly powerful.
It also works with SQL Server backend data.

[Rabbit]

Well, I knew it was a sample database. I never would have posted it if it was a production database.

[Rabbit]

As a general best practice for your extra encryption, you should switch to a stronger algorithm like AES.

You should also use salts, to prevent what you're seeing with gender. A salt will prevent identical messages encrypted with identical passwords from producing identical cipher texts.

[NeoPa]

IslaDogs:
Yes I realise that but of course you are far too well behaved to do anything with that info...?? Yeah, right!

I can't speak for other moderators - except - well I think I probably can. Most of those we promote to moderator are just like you chaps (One of them exactly like one of you as Rabbit is one of course.) who come on here more to help than anything else. I would be happy to vouch for any one of them - though possibly not on my children's lives. I think you can rely on that being pretty safe. What do they say - obscurity is one of the best forms of protection ;-)

I would be interested to hear about the technique used though (via PM) if you're happy to share. You never know - I may even understand it. I've dabbled in hex editing of files before now (Indeed back in the day I dealt quite a lot with data files of many & varied formats.) but only very recently come across (and installed) a hex editor that handles memory tweaking too.

[isladogs]

Perhaps some further explanation about encryption would be useful here.
In a real life application based on this concept, the encrypted data would never be made visible...nor of course would I have revealed the encryption function used. Both were provided here as a 'proof of concept'

RC4 uses 128-bit encryption and is reversible in the sense that the same cipher both encrypts and decrypts the text. This makes coding much simpler though of course makes it less secure than something like AES.
Nevertheless, even without salting, it is almost impossible to decrypt the data without knowing the cipher.

Encoding is easily cracked as it produces predictable and always repeatable results for each character that has been encoded
By contrast, the encrypted characters depend not only on the cipher used but also on the length of the string and the position within the string.

As it mentions in the Web article, there is of course little purpose in encrypting the data for fields with short repeatable data such as Gender and Title. I did it just for completeness. But whilst you can easily deduce which characters correspond to say M, F or r in those fields, it doesn't apply that the same characters apply elsewhere in other longer strings. For example, each email address contains the symbol @ but if you compare the encrypted data for each email record, you won't be able to deduce any pattern.

Interestingly the RC4 function was made publicly available around 20 years ago but the original code contained a flaw which in certain situations causes vba error 9 - subscript out of range. I published a correction to the RC4 code in my Web article.

@NeoPa
I will send you a PM shortly. Whilst using a hex editor will reveal some information, it wouldn't have led anyone to the BE password in this app ...at least not without doing some major work on it first.

I first discovered the approach Rabbit used a couple of years ago and have used it myself on several occasions to recover passwords for clients. Thankfully it isn't widely known...at least amongst Access developers 😏

EDIT:
Hopefully I've erred on the side of caution in my comments above. However, I'm happy for mods to remove anything that may be considered inappropriate in a public thread

[Rabbit]

In a real life application based on this concept, the encrypted data would never be made visible...nor of course would I have revealed the encryption function used.

The purpose of encryption is to protect data when it is inevitably made visible. It's also very common to reveal what encryption function is being used. For example, the functions protecting HTTPS and wifi are widely known. It's not the hiding of the function that provides the security, it's the algorithm itself that provides the security. Knowing something uses AES doesn't mean the encryption is more easily breakable. Hiding the function is just one form of obfuscation.

RC4 uses 128-bit encryption and is reversible in the sense that the same cipher both encrypts and decrypts the text. This makes coding much simpler though of course makes it less secure than something like AES.
Nevertheless, even without salting, it is almost impossible to decrypt the data without knowing the cipher.

RC4 in its original form is considered broken at this point in time. The old WEP protocol for wifi uses RC4 with a salt and a program can crack the password in a couple of minutes.

As it mentions in the Web article, there is of course little purpose in encrypting the data for fields with short repeatable data such as Gender and Title. I did it just for completeness. But whilst you can easily deduce which characters correspond to say M, F or r in those fields, it doesn't apply that the same characters apply elsewhere in other longer strings. For example, each email address contains the symbol @ but if you compare the encrypted data for each email record, you won't be able to deduce any pattern.

One of the reasons RC4 is broken is that you can deduce a pattern.

[isladogs]

Hi Rabbit

I realise your knowledge of the topic is way above mine but I'll try and explain what I meant. Hopefully without digging a big hole for myself by doing so!

My understanding is that RC4 is no longer considered acceptable in terms of modern encryption standards because the code is publicly available and because it is reversible. Therefore it is true that it can be attacked and isn't recommended for use in new 'commercial' applications.
See RC4 encryption - Wikipedia

Yes there are patterns but I meant that, in practical terms, none of us working as amateur hackers would be able to decrypt the data just by looking at the encrypted version - that is without the use of significant computational power. Professional hacking teams would of course have such access and would use it if the data was sufficiently valuable

Anyway, lets imagine that you have found out the BE password, opened the BE database, removed the deep hidden table attributes and are faced with the encrypted data. Also that you have no access to a decrypted version of that data.
Now lets start with just the '@' symbol in the email field whose position wouldn't actually be known to me:

As the screenshot hopefully makes clear, the encrypted character for '@' depends on its position in the string...though not on the overall string length as I previously stated

So it is clear there is indeed a pattern and similar patterns would exist for all other characters in that field. However, the time it would take me to retrieve those decrypted email addresses would be prohibitive. I agree that it wouldn't stop professional hacking teams.

Although I didn't do so, each field / table could be encrypted using a different cipher which would make it harder still. Salting would undoubtedly help further and using AES or similar would be much better still.

However, if I provided an unlocked database with a table of RC4 encrypted data and nothing to guide you as to what cipher or ciphers were used for each field, are you telling me you could still decrypt it within a reasonable time interval? If the answer is yes, are you willing to do so?

[bakertaylor28]

The thing is that in a word- you don't- you don't need to. There's four basic strategies to hack a password with respect to an application. They are:

1. Brute force (sitting down at a terminal and trying random passwords until one works).
2. Dictionary Attack. ( Using a dictionary of common passwords or previously dumped passwords and trying them sequentially.)
3. MITM attack (get the password by capturing data from legitimate user, e.g. techniques like TCP packet sniffing, etc.).
4. Dictionary Attack with Rainbow Tables ( Same as Dictionary attack but where the app passes the password through an encryption cypher in order to "disguise" it in the database so that the password as stored in the database is not the true "password", but a cryptographic conversion of the password.)

We mitigate these as follows:
1. Brute Force is mitigated by controlling the number of consecutive login attempts before having to wait before you can try again. So we program the password feature with a three strike rule and make the client wait a time before they're allowed another login attempt. (critical apps may even "Lock" the account and require a reset sequence that challenges the person's credentials with more scrutiny- such as a bank account asking security questions that only the account owner will know the answer to.)

2. Dictionary attacks are mitigated the same way we mitigate brute force. We may also check a user's user agent (make sure they're not submitting information with a bot or a script.)

3. MITM attacks are more a problem with the client. The programer usually doesn't address them directly, other than building their code to be secure, in general. (such as by using prepared statements when working with PHP/SQL, etc.). This is where how you write the code makes all the difference, because the app may well be fooled into returning a password list, if you haven't used secure programming logic AND written the code CORRECTLY.

4. Rainbow tables are only partially effective. They require two things: 1. That I know what cypher the programmer used. 2. It relies on the dictionary attack. Simply put, I take every password in the dictionary file and pass it through the cypher, and then compile the converted dictionary file to run a dictionary attack. This is where using a strong cypher makes a difference (the more random the output string the better) and where mitigating a dictionary attack is the real key to dealing with rainbow tables.

In short, most hackers aren't going to attempt to pass fake credentials within an application itself, because they usually don't want to take the risk of causing the application not to run as otherwise intended. (e.g. its a big risk of "breaking" the app- which would defeat the purpose of gaining password credentials.) Therefore, you're trying to protect against an attack that largely doesn't exist outside the scope of extremely LARGE applications, such as an O.S. and the like. Don't overthink the project.

That SAID, if you really want to do it:
Calculate the SHA1 hash checksum, store it in a separate database and compare old SHA256 with New SHA256 in a separate database. If the database files have been changed in any way, they won't have an identical hash. SHA256 has not yet been broken, therefore its theoretically impossible to cause a hash collision. To go stronger, you could use something like BLAKE2sp but its hardly necessary to go that far. However, to do this you're going to need to write the app in a high-level language like C, perl, or the like. The U.S. government still uses COBOL for this sort of thing.

[isladogs]

@bakertaylor28
Thank you for your lengthy and constructive contribution.
However I'm not clear if you are just responding to the thread title or to later posts as the thread has developed / changed.

I understand how password hacking is done but I'm not clear how your post fits in to what was being asked originally or to recent posts in the thread

EDIT
You added an extra final paragraph whilst I was replying. I think that explains what your post was referring to. Thanks

[bakertaylor28]

Sorry about changing while you was replying but rather, I tend to do that due to cognitive style. That said, I was responding in general as an overview in light of the entire thread, and explaining things in the sense of an overview of programming and hacking in particular- the thought processes via which hackers think in the real world and how things tend to happen more than not. One of the most secure ways of deploying applications is in a mainframe environment. (The reason the government and large corporations like banks still use the old IBM mainframe), however this requires mastery of COBOL, FORTRAN, and the like. a Mainframe environment can be emulated using tech like a tk4- server, BUT it requires that you've mastered the IBM Mainframe environment, which is a very steep learning curve even for those seasoned in the more contemporary programming languages.

[Rabbit]

My understanding is that RC4 is no longer considered acceptable in terms of modern encryption standards because the code is publicly available and because it is reversible. Therefore it is true that it can be attacked and isn't recommended for use in new 'commercial' applications.

That's not why it's considered broken, it's considered broken because the algorithm has too many weaknesses. AES code is also publicly available but is unbroken. I'm not quite sure what you mean by reversible, but in encryption, reversible means that you can obtain the original plain text from the cipher text. In the cryptographic sense, AES is also reversible. An example of a non-reversible function are hash algorithms.

Yes there are patterns but I meant that, in practical terms, none of us working as amateur hackers would be able to decrypt the data just by looking at the encrypted version - that is without the use of significant computational power. Professional hacking teams would of course have such access and would use it if the data was sufficiently valuable

Anyway, lets imagine that you have found out the BE password, opened the BE database, removed the deep hidden table attributes and are faced with the encrypted data. Also that you have no access to a decrypted version of that data.

So it is clear there is indeed a pattern and similar patterns would exist for all other characters in that field. However, the time it would take me to retrieve those decrypted email addresses would be prohibitive. I agree that it wouldn't stop professional hacking teams.

That can be said about many algorithms. You could use a vigenere or xor cipher in place of rc4 and achieve protection against amateurs. But you don't need significant computational power to break any of them. You can break RC4 with free tools available online in a couple of minutes on a desktop computer.

However, if I provided an unlocked database with a table of RC4 encrypted data and nothing to guide you as to what cipher or ciphers were used for each field, are you telling me you could still decrypt it within a reasonable time interval? If the answer is yes, are you willing to do so?

Reasonable time interval? Absolutely, even if I don't know which algorithm is being used, it takes minutes to run a crack on several well known but weak algorithms with free tools to see if anything comes out of them.

[NeoPa]

IslaDogs:
Hopefully I've erred on the side of caution in my comments above. However, I'm happy for mods to remove anything that may be considered inappropriate in a public thread

I see nothing here that is inappropriate. I'm keeping an eye on the thread but so far all I see is a very interesting & informative discussion.

[isladogs]

@Rabbit
I see I have some further research to do. I'll be looking at some of the free tools today. Many thanks for your explanations.
If its OK with you, I may make further contact via PM

EDIT: I referred to RC4 as reversible encryption because the same cipher and key will both encrypt the text and then decrypt it again.

@Bakertaylor
As this thread has progressed, it has become clear that the original question really is of no consequence.
Its really not worth the effort involved as you suggested

@NeoPa.
Thanks. I agree but thought I'd raise the point.
The conversation has become much more useful than expected from the original post I made.
Nobody has publicly described any techniques for hacking applications nor provided any links which do so.

[isladogs]

UPDATE:
I'm still working on integrating AES encryption but haven't got there yet

In the meantime, another partly completed example to that thread that I had already been working on

Its an encrypted ACCDE file made in A2010 32-bit with password FrankTheTank

It has one password protected form and one deep hidden table
Unlocking the file will be relatively easy. The challenge is just to do the following:
1. Find out the password to the form
2. Decrypt the deep hidden table and email or PM me the decrypted version
That's all.
Simples ....at least for Rabbits(?)

NOTE:
1. Its far from finished & I may have left some unintended 'back doors'. If so. it will be easier than intended
2. The attached file should open in any 32-bit version of Access from 2010 onwards. If anyone would like a 64-bit version, let me know