Secure Code....

[Haroundb]

Questions:
Is there a possibility to write secure code in MS Access?
Out of 10 MS Access scores how much?
Can someone read the mdb, mde file with a tool other than Access?
Which programming language is better for security?



Thanks in advance for your help

[NoellaG]

Hi,

there are several possibilities and levels of security you can apply, for instance:

- applying a password to the entire access file,
- locking down the code with a password
- up to access 2003: creating user groups and setting permessions
- programming your own security
- making an executable that runs with Access runtime

up to you to choose the one you want.

[Haroundb]

Thanks NorllaG for the input, but I am asking about the next level of security. Is it possible to penetrate the code even if I did what you mentioned above?

[NoellaG]

Hi,

of course it's always very dangerous to say something can't be hacked... but I would say that if you make an executable it's fairly hacking-free.
For the rest it depends on how well you do it, like all protection.

greetings
NG

[pkstormy]

An mde file is the most secure method for not allowing others to see your code (such as users). There are some companies that can recover some of the code in an mde but it is limited and usually only entails the code in some modules, not within forms. I've rarely seen a full mde be recovered unless it was basic in nature with very little coding. These are of course pay to get the mde restored to some point type companies.

As far as users utilizing an mde, if the code bombs out, they will not be able to see the code where it bombed out on and will just get an error message. Plus the mde will perform much more efficiently.

But I'm a believer though that you should always supply the mdb source file for the company (not for the users to use though) to allow the company to upgrade the application in the future. If not supplying it with the company, then have a 3rd party lawyer hold on to it in case you go out of business/leave the company. Otherwise you may find the company trying to find you later when they do try to upsize and your code no longer works. I also believe that a company should have the right to fix errors (nobody's code is completely error-free) in the future or perhaps make updates. (again personally), I believe the company has bought the right to do this when they buy your application (unless your a company such as Quickbooks which will most likely continue to support fixes/make upgrades.)

I will usually put in my own security level table system (I don't like MSAccess's security which is hackable - I have a utility which lets me see all the logins/passwords in an mdw file). You can see the code bank for an example on creating a security level table. It allows the certain admin users to administer rights for other users.

But I usually frown on not giving the company the source mdb file in preventing them for making updates. Since most of these are customized applications specific for the company, it's doubtful the companies going to take your product and sell it to others.

Since I work for the UW Hospital, I'm bouncing in/out of dozens of in-house built applications throughout the day. I'll make an mde for the users and implement my own security but as far as the mdb file goes, I keep that in my own personal (development) folder to quickly make changes and roll out new code. It wouldn't pay to make it more difficult for me to do this by trying to use bypassshiftkey code or other protection measures against other in-house developers (we're all on the same team anyway.) If I leave the UW Hospital, my code stays with them since it is technically theirs anyway with me being an employee. I usually focus on snippets of code that I like to re-use from one application from another (again, see the coding examples section.)

There's a general rule among developers that if you do utilize someone else's code, you leave the credits for that developer within the code. Not a lot of developers take the time to try and hide/protect their code from others and most would rather freely distribute and see their routines used among others developers (I'm one of them.) Most of the code can be found one way or another throughout the web anyway so protecting a method that you think should be proprietary has most likely been done in one way or another or can be done by finding bits and pieces of the solution somewhere.

[pkstormy]

As far as which specific programming language is more secure than others, Visual Basic allowed you to create *.exe files which I've never seen hackable without the source code. But visual basic has now been replaced with vb.net (not sure about vb.net). You can still find copies of visual basic 5.0/6.0 around (I used to do a lot of coding with it.)

I made a few visual basic (.exe) games in the coding examples section if you're interested in seeing what they are like. You only have the *.exe file which again, you wouldn't be able to undo to see the source code.

As far as I know, *.exe files are unhackable. But you can't create an *.exe with MSAccess.

[pkstormy]

One last note on development. If you are developing an application for another company and are worried about payment, I usually supply them with the mde until the final payment is made. Then they get the mdb file. That way I can enforce enabling/disabling certain features in the mde until payment is made.

If you're worried about security, I personally like to use SQL Server as all my backends (more security options) but also still use a security level table found here: https://www.accessforums.net/code-re...mple-7538.html

We control security at 3 levels at the hospital:
1. The user must have permissions to the folder where the mde resides or they will never even see the mde file to open it.
2. The user must be in the 'user' table with security level permissions or the mde will close out.
3. The user must be in SQL Server for permissions or they won't be able to update any data and will get errors when opening the mde.

The above meets any HIPAA security requirements needed for our hospital applications.


I also utilize this method: https://www.accessforums.net/code-re...mple-7571.html
(the frmMainFormBackground technique)
to prevent users from gaining access to the upper MSAccess menu system (and thus close out of forms to get behind the scenes). It's a simple technique that works quite well since most users don't know the hold-the-shift key and open the mde trick. It also allows me to quickly get behind the scenes to make updates.

Now a user could potentially hold the shift key down and open the mde and avoid the startup to get behind the scenes (but they still wouldn't see any coding). If they decided to do some updating of tables on their own without the interface, I write certain values to the table via only code and would eventually see that these values are not populating. Using SQL Server I could see who was making the updates and that person and I would then have a little chat about bypassing the startup and entering data directly into a table (since this is more of an intential act.)

Are there any specific concerns you have not addressed yet?

[ajetrumpet]

Questions:
Is there a possibility to write secure code in MS Access?
Out of 10 MS Access scores how much?
Can someone read the mdb, mde file with a tool other than Access?
Which programming language is better for security?

Thanks in advance for your help

Haround,

I'd like to add something just from experience. Do you draft a contract with your clients? If you do, I would recommend putting a clause in that releases you from any liability of security breaches and possibly the limits of Access.

There will always be hackers out there trying to break security and the intelligent business community knows this. If you are going to sell an app to someone that you do not trust 100% then draft a contract and get signatures. That will protect you against any issue of them accidentally compromising their own security, or worse, you giving verbal or documented advice about supposed "facts" and have those facts proven wrong by a hacker, etc... That'll lead you to the lawyers I think faster than anything.

Unfortunately I think people look at technology experts as promise makers. More than anything, avoid making promises about your application because technology has too many variables involved to ever make a promise 100% concrete. There is just too much information. If you are working with the right people though, they already know this and won't have a problem bearing a little bit of the risk that will never go away when purchasing a tech program.

[Haroundb]

Thanks everyone for the input but I was aiming primarily on the Code section. I need to know how difficult/easy it is to penetrate VBA specially in Access.

Secondly I would like to know mde as a file how secure it is ?

[NoellaG]

Hi,

if you secure the code section by setting a password to your code, (Tools -> Project properties)
and you use a large enough and safe password (combination of chars, numbers, ...) it's fairly difficult to crack that.