Input on securing FE/BE access database

Posted on 2011-10-07
Last Modified: 2012-08-13
Hi Experts, I have a FE/BE Access db application that I want to tighten up. The BE is on a network share, and right now any user who has access to the share can open the BE and mess with it. Not good.

I am using Access 2007, and the BE is an .accdb.

Here is the simple version of what I am trying to do, and I would appreciate input from anyone who can see a gaping hole in this model:

1) "Encrypt with password" the BE

2) Make user-specific Front-end "template" files to be copied down to users local machine. These are password-encrypted.

3) Make a "management" db that has a table of users, the path to their Front-end template, and the password for the template. This is also password-encrypted.

4) Make a "trigger" db (containing code module only) which the user uses to launch the application. This would connect to the users table in the management db using ADO, and would be distributed as an .accde so it is not possible to find out the password to the management db.

5) When user opens the "trigger" db, it gets their network login name, connects to the managment db to determine the appropriate FE template and password, creates an .accde FE on the local machine, and opens it for the user.

I think I can basically achieve pass-through authentication this way... fingers crossed! If anyone tries to open either a FE or the BE without using the launcher, they will be presented with the "passord required" box.


Question by:McOz
    1 Comment
    LVL 84

    Accepted Solution

    Assuming that you have different passwords for the "launcher" database and the "live" database, then this sounds as if that's about as secure as you can get with an Access backend. In effect, your enduser would have no knowledge of the actual password being used for the Backend database, which should preclude all but the most determine users from getting to the data.

    Note however that once that BE is opened through table links and such, a knowledgeable user could use the GetObject("Access.Application") method to "grab" that object, and would have full access to the tables. This would be a very, very remote possibility, of course, but just be aware that is the one exploit that sometimes crops up (but again, very rarely).

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Find Ransomware Secrets With All-Source Analysis

    Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

    Healthcare organizations in the United States must adhere to the guidance of both the HIPAA (Health Insurance Portability and Accountability Act) and HITECH (Health Information Technology for Economic and Clinical Health Act) for securing and protec…
    If you're not part of the solution, you're part of the problem.   Tips on how to secure IoT devices, even the dumbest ones, so they can't be used as part of a DDoS botnet.  Use PRTG Network Monitor as one of the building blocks, to detect unusual…
    Basics of query design. Shows you how to construct a simple query by adding tables, perform joins, defining output columns, perform sorting, and apply criteria.
    In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    20 Experts available now in Live!

    Get 1:1 Help Now