VBA code to detect if a password has been changed

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