[MSACC2010] Password protect backend?

[jonathanchye]

Hi all,

I have a database built using MS Access 2010 which is a split database. Everything is working fine until some users found out the BE location. *Someone* then managed to change some user details in the tables. Luckily I have backups but I really want to prevent this happening again.

I noticed there is an option to password protect the BE but will this also mean users will have to enter a password when connecting from their FE? If so, are there any other alternatives to keep the BE safe? I was thinking of a simple login form on opening the DB but ultimately this can also be bypassed plus it's a lot of effort just to password protect the BE.

This is a fairly large company so I just wanted to make sure before I commit any changes.

Thank you.

 

[DavidAtWork]

Depends on how much you want to restrict users being able to see the database objects. If they only require access to the FE and all functionality is built in to the database and users do not need to create queries/reports, then you could consider locking users out completely by creating and MDE file and running code on startup that disables all menus and hides the DB window. The database can be in a state where the bypass keys are disabled, so they can't get in that way. There are hidden ways to activate code that will re-enable menus and show the DB window should you wish to get to the backend although you won't be able to get to the VB window, so you'll need to keep updating the MDE file, when you make any changes, from the current mdb or accdb file

David

 

[PaulO]

You could perhaps also consider hiding all the tables in the BE file, just in case users still manage to find a way of loading it.

 

[JANR]

There isen't a fullproof way to secure an Access BE, sure you can password protect the BE but the password is exposed in the connection-string to the BE tables so a savy hacker will be able to read it and use it. But for the curious it should stop them from messing with the tables.

To fully lockdown the BE you have to look into using SQL-Server as a backend.

JR

 

[jonathanchye]

Thanks for all the answers!

I think 90% for the end users will not be savvy enough to hack into connection string as I distribute the FE as an ACCDE file. I also know how to build in a Shift bypass etc but thinking back I would have to update all the queries and reports in the FE to include the password. That might be a little bit difficult and also seems like a lot of work. Initially thinking of something much simpler such as implementing a password to the BE after splitting.

The company is considering upgrading to SQL server and I guess I will propose this in the coming year as more and more data are becoming sensitive and mission critical.

I am also considering Sharepoint 2010 as an another solution. I would think implementation could be much faster moving from Access 2010 to Sharepoint vs Access 2010 to MS SQL Server? I only had a brief introduction to Sharepoint 2010 but it does look pretty promising.

 

[DavidAtWork]

"There isen't a fullproof way to secure an Access BE"
If you prevent users from being able to see any menus, the db window or db objects, they can't see properties for any objects and therefore any connection string data.
David

 

[DJkarl]

"There isen't a fullproof way to secure an Access BE"
If you prevent users from being able to see any menus, the db window or db objects, they can't see properties for any objects and therefore any connection string data.
David

They could hold down the shift key and bypass all those security measures, if you haven't disabled the shift key that is, and even if you have a savy user could turn it back on via code.

 

[JANR]

If you prevent users from being able to see any menus, the db window or db objects, they can't see properties for any objects and therefore any connection string data.

Thats true for the normal user, but if you know how it isen't very difficult

just hacked my own test db

But if your interested here is a securety consept discussed at UtterAccess: http://www.utteraccess.com/forum/Access-2007-security-t1242310.html&hl=midtier

JR

 

[JANR]

Attached is a very basic sample of the consept in the link I gave.

-Unzip the folder to C:\
-Open the MyFrontEnd.accdb (access 2010)
-Try and open the table MyTbl, you should get an error of an invalid password.
-Now open the form frmConnection and let it stay open, you should now easily open the table "MyTbl"

When you close the form which would be a hidden splashform in an application which only purpose is to maintain an open connection to the backend and serve as a holder of the password to the backend.

The forms load-event calls the function fConnect() and the close-event calls fDisconnect()

Now password is NOT exposed in the connection string in MsysObjects table and all forms or queries piggy-back this connection as long as the form is open.

It's main weakness is that a wouldbe hacker can use automation explained in the link to learn the password, but for the curious ("soon to get his hands smacked") should be stopped.

Atleast the backend or it's tables can't be accessed directly through other means than knowing the password.

Of course the frontend should be compiled as an accde so the hardcoded password in the module mdlConnect isen't exposed easily.

Here is the code in the module:

Option Compare Database
Option Explicit
 
Public fConnection As Recordset
 
Function fConnect()
Dim sSQL As String
sSQL = "Select * From MyTbl IN '' [MS Access;PWD=dumbass;Database=c:\TestDB\SecureDB.accdb];"
Set fConnection = CurrentDb.OpenRecordset(sSQL, dbOpenSnapshot)
End Function
 
Function fDisconnect()
fConnection.Close
End Function

Hope this helps some as an interim solution.

JR

 

[toast]

Resurrecting an old thread...
With a similar conundrum to the initial poster, am I correct in saying that if you are trying to protect data in the backend there is little point in adding shift bypasses, hiding the navigation pane etc.
You might as well just password protect the db.
If somebody gets past that (woefully easy, unfortunately), they won't need to see anything in the backend... surely all they would do is create a new blank database, link to the backend and supply the password. Now they have access to all the data.
Or am I missing something?

 

[JANR]

If somebody gets past that (woefully easy, unfortunately), they won't need to see anything in the backend... surely all they would do is create a new blank database, link to the backend and supply the password. Now they have access to all the data.

Yes if the hacker knows the password to the BE then you can't stop them messing about, that goes for all systems.

Just don't supply the password in the connectionstring in MsysObject table, that is easy to access for the outside.

JR

 

[Galaxiom]

Even with the password in a module rather than the Connect property of the tables and the code compiled the password is still able to be found unless it is specifically encrypted.

With the data in an Access backend a user could take the file away and crack the password at their leisure.

Access is not secure. End of story. If you need security then use a server backend.

 

[toast]

Thanks for the replies.

With certain people happy to download 'point-and-click' software to crack Access passwords with incredible ease, I thought I must be missing something on the security side of things. But sadly not!

 

[Galaxiom]

With certain people happy to download 'point-and-click' software to crack Access passwords with incredible ease,

More sadly, the security in Access is so pathetic that no special software is even required.

With the standard password protected backend setup, the password can be revealed in a few seconds.

 

[rodmc]

Easiest solution - tell the users anyone caught interfering with the BE then its P45/Sack/Books/Fired/feet wont touch the ground!

Where I work that would be considered gross misconduct

 

[toast]

Again, thanks for the replies.

My main concern is that somebody gets into the BE just once, views the passwords (stored in a users table) and then can log on as somebody else from then on... the chances of somebody picking that up will be pretty remote unfortunately.

And the threat of disciplinary action will probably not be any deterrent (the DB is implemented in an area of the world with little concern for such things).

Should I be using a different design? Or do I just have to live with that / migrate to SQL

 

[rodmc]

Again, thanks for the replies.

My main concern is that somebody gets into the BE just once, views the passwords (stored in a users table) and then can log on as somebody else from then on... the chances of somebody picking that up will be pretty remote unfortunately.

And the threat of disciplinary action will probably not be any deterrent (the DB is implemented in an area of the world with little concern for such things).

Should I be using a different design? Or do I just have to live with that / migrate to SQL

Best bet is to go with SQL back end, well either that or a threat of physical violence

 

[toast]

Or probably a combination of them both!