Secure MS Access front-end from Hex Editor

Alhakeem1977

Registered User.
Local time
Today, 09:34
Joined
Jun 24, 2017
Messages
308
Hi everyone,
I have created MS Access application in MS Access and I was really proud to finish it, it tackes from a lot of time and hard work to achieve this.
But unfortunately, when I present it to our IT they said that it can be hacked easily by Hex Editor.
I would like to protect my application from such editors, is there a way that when my application mapped by the editor to become currpted and no more used.

One more thing, if I connect the front end with SQL Server is possible to avoid stealing my data?

Appreciate advice with the best solution on this matter... Thanks in advance!
 
Hi. Unfortunately, if you're really concerned about security, you picked the wrong tool to use.

What do IT mean exactly by "hacking with a Hex Editor?" Did they explain that or give you any details of what a Hex Editor will do to your app?
 
@theDBguy I suspect he means finding passwords using a HEx editor.
That would be a good guess! But if that's the case, then the OP can tell IT that it's not true anymore that "it can be hacked easily by Hex Editor."
 
It isn't possible to prevent anyone opening an Access database (or any other file) with a hex editor.
However, what is much more important is the amount of information that can be obtained by doing so.

As my website article (see link in Minty's post) clearly shows, passwords are now far more secure in ACCDB files than used to be the case with the older MDB format. However, the data in an unencrypted ACCDB file isn't secure from a hex editor.
If you encrypt your ACCDB files with a password and then convert to ACCDE, the contents are secure enough from all but the most determined hacker who has sufficient time and determination to invest in overcoming that.

It is true that there is still a way in which an encrypted ACCDE file could be read ...
Note that I'm being deliberately vague in how I'm wording that.
However the same method (which I'm not going to describe for obvious reasons) will also allow users to view the contents of other databases including the much more secure SQL Server
 
Last edited:
to answer this question
is there a way that when my application mapped by the editor to become currpted and no more used.
No - all you can do is make the content as unreadable as possible with a hex editor - or even notepad. A .accde is a good start

and this one
if I connect the front end with SQL Server is possible to avoid stealing my data?
that depends on how your app works - can users print the contents of entire tables via a form or report? or copy paste to excel or notepad? or email? Have you protected against sql injection? Do users have sight of tables and queries? This sort of protection requires a policy (your IT dept may have such a policy) and is usually built in from the initial design.
 
Last edited:
However the same method (which I'm not going to describe for obvious reasons) will also allow users to view the contents of other databases including the much more secure SQL Server
Not if the security is configured properly. Users are not given direct access to the data files in SQL Server (or other rdms). The only access is via the SQL Server service and that access is defined by permissions.
 
Hi Galaxiom.
Sorry to disagree but there is a way which allows indirect access to linked SQL Server tables without opening Access.
 
Sorry to disagree but there is a way which allows indirect access to linked SQL Server tables without opening Access.
Never mind Access or linked tables. Anyone can query the server according to the user permissions granted to them by the server. But that is unsurprising. If they don't have permissions they can't see the data.

If it is an SQL Server login (rather than Windows AD) and those credentials are encrypted in an application they could try to hack the application to recover them but that is not trivial. If they are behind a properly secured web application there is no way anyone can get to the data other than through a brute force password attack.
 
The approach is disturbingly simple.
You're not on the right lines but I have already given a clue.
I'm not going to give any more info in a public thread. However feel free to contact me via email or a PM if you wish.
 
Thanks to all of you for the worth and your earliest responses.
Actually one of the videos I watched shows that Hex editor can change the db Password easily, I am wondering how Microsoft did not find a way to secure their applications...
If you would get time, please watch YouTube link

EDITED BY THE_DOC_MAN - Video link removed. Link demonstrates a way to hack a database, which is contrary to site policies.
 
Last edited by a moderator:
Actually the video I watched in your link doesn't show how to do that.
It is true that VBA passwords can be bypassed which is why they should never be relied upon.
MDB database passwords are easily hacked as my web article made clear.
ACCDB password protection uses 128-bit encryption and can only be hacked by brute force attacks.
For a strong passwords this can take several days so, in general, isn't worth the effort.

Nevertheless as the video does give away useful info to hackers, I ask that you remove the link from your post in order to minimise damage.
 
Thanks to all of you for the worth and your earliest responses.
Actually one of the videos I watched shows that Hex editor can change the db Password easily, I am wondering how Microsoft did not find a way to secure their applications...
If you would get time, please watch YouTube link
Hi. The video link you provided is not the same as truly protecting your application from hackers. All you have to do is distribute your database application as a compiled ACCDE, and they can use a Hex Editor all day long, but they still won't get to your code.

So, if that's all your IT is worried about, then give them a compiled ACCDE instead of a ACCDB file.
 
Last edited:
Sorry to disagree but there is a way which allows indirect access to linked SQL Server tables without opening Access.
I built an app used by sophisticated engineers who were perfectly capable of building their own Access database and linking directly to the SQL Server so to thwart that, I had the DBA change their logins using an algorithm that we developed so we could always come up with the same string given the company assigned login. The user was never given this UserID. Also, the DBA and I controlled the password and changed it frequently.
they said that it can be hacked easily by Hex Editor.
Why is that relevant? Are you selling this app to the public or are you using it at your own company or a client company? If you developed the software for someone it is a work for hire and technically unless you have a contract giving you ownership, the person who paid for it owns it.
 
Actually the video I watched in your link doesn't show how to do that.
It is true that VBA passwords can be bypassed which is why they should never be relied upon.
MDB database passwords are easily hacked as my web article made clear.
ACCDB password protection uses 128-bit encryption and can only be hacked by brute force attacks.
For a strong passwords this can take several days so, in general, isn't worth the effort.

Nevertheless as the video does give away useful info to hackers, I ask that you remove the link from your post in order to minimise damage.

Sorry I was unable to read your reply.
I am really sorry because I posted the wrong link.

Just to clarify can I post the right YouTube link?
 
The site's preference is that we do not feed hackers. So if you posted something that would allow someone to break into a database, it is something we don't do. The issue is legal liability. In many jurisdictions, if you provide assistance to someone who does damage to someone's database, you can become legally liable as an accomplice for "Theft of computer services" or "(Intellectual) property damage" depending on the way the local laws are written. In my home state of Louisiana, if you do as much as $2500 in damages, it is a class E felony with prison time and a hefty fine, not to mention Tort liability based on the criminal action. As you can guess, that is a can of worms we don't want to open.

However, your interest and your attempt to contribute to the site ARE appreciated.
 
My response would have been exactly the same as Doc's. I do hope you understand why I wanted the link removed.

We do appreciate your interest in making your databases as secure as possible,
Also that you will appreciate why some of the responses are at times deliberately evasive.

However, if you feel the video gives information not dealt with in my various security articles and that such information might assist me to improve those articles, then feel free to contact me by email or PM with the relevant link
 
Thanks a lot for all the informations provided, I really appreciate all the responses on this thread.

I hope one day find the way to secure my applications.

Thanks again for your support and guidance. 👍
 

Users who are viewing this thread

Back
Top Bottom